TODO


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

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

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.

Get rid of GitPython usage

 We're using GitPython only at the very lowest level; it would be
 30-40 lines of code to replace it entirely which would make git-bz
 much easier to install for people. And would also allow some
 improvements (display command output on error, for example) and
 allow removing some cases where we drop out to subprocess to get
 around limitations in the GitPython cmd module.

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.