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
78
79
80
81
82
83
84
85
86
87
88
|
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
Always do 'git bz attach --edit'
Prompting doesn't have that much of an advantage over the edit buffer -
maybe a little easier to abort. And eliminating the need for --edit would
eliminate people having to find out about it and remember to specify it.
Make it harder to change the description for 'git bz attach'
'git bz push' really wants the description not to have been edited, but
it's pretty easy to accidentally edit the description; it might even
seem like changing it to 'new version of' is a good idea.
It probably just shouldn't be possible to edit the description at all.
We could do something like uncommenting:
# Description: Foo bar
To change it, but it doesn't seem useful.
Automatically guess obvious obsoletes
When doing attach -e/--edit, and there is an existing patch who's description
matches the Subject of the attachment, start the Obsoletes line
uncommented?
Handle redirects:
Should follow redirects, both to different URLs and http => https
Better display of errors
The switch to XML-RPC greatly improves errors when filing a new bug,
but other problems (e.g., having stale login cookies when making an
attachment) still just dump HTML pages error pages to the console.
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.
Apply patches as a single mailbox
Instead of running 'git am' separately for each patch, combine
them into a mailbox and provide that to 'git am'. This will allow
'git am --resolved' to continue properly. It will, however,
require doing the 'add-url' work ahead of time by rewritig the
patches, since if 'git am' stops, we don't get called at the
end.
Pass --3way to git-am
git am --3way (on application failure, attempt to use the blob
IDs in the commit to do a 3-way merge) is way, way better when
it works then just stopping and making the user do it by hand.
git am --reject (put rejects into .reject files, ignore the rest)
is also useful, though it interacts badly with --3way; that
probably needs to be fixed upstream.
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.
The double commits could be avoided if if we did the 'rewrite patch'
thing for 'git bz apply'- then we could use it here too and just
pass the whole sequence to 'git am'. And by setting
GIT_REFLOG_ACTION='bz add-url' it should work almost perfectly.
It wouldn't give a single reflog entry, but 'git rebase' and
'git am' don't show up as a single entry either. 'git rebase'
does show up as a single entry in 'git reflog show master'; that's
done by detaching from the branch during the operation. We could
do that as well.
|
