1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
Ideas about additions for git-bz
================================
The presence of an idea here does not necessarily imply that I have
any intention of working on it myself.
- Owen
Reconsider initial description for 'git bz file'
Right now, if you have only a single patch, the initial description is the body
of the bug, and the attachment is done without any other comment. (But
still adds a comment to the bug because every attachment has a comment.)
I often find I want to have a few sentences about why I'm making the
change different than the body of the commit (or ask someone to look at the
patch or something), so I've been adding extra text and a separator,
which leaves it unclear what the stuff after the separator is.
Better way to handle it:
- Start off the initial description empty in the editor
- If the user fills it in, use that as the initial description
and the body of the commit as the comment.
- If the user leaves it empty use the body as the initial description
as currently.
Allow editing comment used for attachments
When attaching a revised version of a patch, you really want to be
able to edit the comment to say what has changed. 'attach' should
support -e/--edit to do this.
In the edit buffer would be commented out lines:
# Obsoletes: 23212 - Frobinificate faster
That you could uncomment to obsolete old patches.
Allow specifying a default product/component for 'git bz file'
Specifying the product/component in the global git config would
be a bit silly/dangerous, but doing it locally in the git config
for a single repo would be quit useful.
Use XML-RPC when available.
Maybe use python-bugzilla: http://fedorahosted.org/python-bugzilla/
Not sure there are a lot of advantages to this; one thing that it
might be possible to do with this is allow the user to specify only
the product and get an interactive list of components. Also, better
error handling.
Handle redirects:
Should follow redirects, both to different URLs and http => https
Better display of errors
Currently specifying a non-existent product/component just dumps
out raw HTML for the reply. Etc.
More general patch application
'git bz apply' currently only handles patches formated with
'git format-patch', it should be able to apply general patches
as well. For general patches, you would use information from
bugzilla to prime the author and commit message, but allow
further editing of the commit message.
Make -u/--add-url kinder on the reflog
-u works by resetting, then on each patch, running git cherry-pick
followed by git commit --amend. It would be nice to only have one
(informative) reflog entry for the entire process, or at least avoid
the double commits.
|
