Right now this only handles r=, but I suppose we could also add support for f= and sr=

I think we did check for this prior to the great bzapi rewrite and asked the user what to do. Now we produce commits like "Bug XXX - Bug YYY - msg", which nobody likes.

gecko$ git bz apply 1291642
Traceback (most recent call last):
File "/Users/past/src/git-bz-moz/git-bz", line 1788, in
do_apply(*args)
File "/Users/past/src/git-bz-moz/git-bz", line 1138, in do_apply
attachment_data=True)
File "/Users/past/src/git-bz-moz/git-bz", line 878, in load
bug._load(bug_reference.id, attachment_data)
File "/Users/past/src/git-bz-moz/git-bz", line 822, in _load
self.patches.append(BugAttachment(a))
File "/Users/past/src/git-bz-moz/git-bz", line 784, in init
diff,
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 10499: ordinal not in range(128)

Manually downloading the diff and applying it using 'git am' works though.

If you try to set an invalid reviewer, like :notavalidreviewer then you get a dump of some HTML page to your console, which isn't useful.

Regularly takes a minute before my $EDITOR gets popped up.

I run it like this (in the most recent case, which was one of the slow ones):

git bz file 'Firefox/Developer Tools' -e HEAD^

Just pulled and now get:

Traceback (most recent call last):
  File "/home/froydnj/bin/git-bz", line 69, in <module>
    import bzauth
  File "/home/froydnj/src/git-bz-moz/bzauth.py", line 33, in <module>
    import requests
ImportError: No module named requests

I guess we need to say something about having https://pypi.python.org/pypi/requests installed? (Things appear to work OK after I installed that...)

This is sort of obvious that it doesn't in hindsight, but it would be super-convenient.

Carrying forward review on a patch (or just self-reviewing a trivial patch) by uncommenting the :me option leads to:

Multiple bugzilla users matching ":me":

  1. Dave Justice [:JSON_voorhees / :meandave] <[email protected]>
  2. Tobias Kristiansson [:mediocrity] <[email protected]>
  3. Michael K. Edwards (:medwards) <[email protected]>
  4. Mekki MacAulay [:mekki] <[email protected]>
  5. Agamemnon Skepetaris [:memos] <[email protected]>
  6. Merike (:merike) <[email protected]>
  7. Melissa O'Connor [:melissa] <[email protected]>
  n. None

  a. Abort

which is unpleasant. I'm not sure what broke this, but we should fix it.

Found multiple bug references specified commits:
https://bugzilla.mozilla.orgNone/show_bug.cgi?id=1001587
https://bugzilla.mozilla.orgNone/show_bug.cgi?id=796061

In my REST API rewrite, I just copied files over from the version-control-tools repository but it should be done more properly, maybe initially by a subrepository and eventually probably by moving this code into that repo.

Attempting git bz file -e 'Core/Video/Audio' ID on Mozilla's bugzilla results in (somewhat mysteriously) filing a bug for product "Core", component "Video". Trying to rely on automatically using the setting bz.default-product with git bz file -e 'Video/Audio' ID doesn't work either, because git-bz assumes you're trying to file something in the "Video" product.

There's a lot of little bits of code to support this, but it doesn't seem useful.

I haven't looked into this in great detail, but it is a little different. This may just be because there's no -e. It should work the same way.

Currently the 2fa implementation on bugzilla has changed cookies to expire at the end of the session. This breaks git-bz-moz, as the cookies are no longer saved to the cookies.sqlite file.

This may change again, follow the dicussion in bug 1202281.

However, it may be time to consider fixing issue #30 and use the API keys that are now be available.

This lets you update bugzilla at the same time as you do a push (I think), which doesn't seem super useful given that we have Pulsebot, so I'm inclined to remove it if there are no objections. I have found users at Mozilla for every other command, so maybe somebody uses this one.

...whereas if I were to file a new bug with a commit ending in "; r=froydnj", the "; r=froydnj" would not appear in the bug title.

See, for instance, https://bugzilla.mozilla.org/show_bug.cgi?id=1413538

It's possible that I could manually edit the r= information out in this case, but it would really be much nicer if it were automatically stripped.

I'm using git-cinnabar, but the stack points to git-bz-moz so I'm filing here.

STR

In a local git-cinnabar clone of mozilla-central (e6b1d0421ae97595aa632d3de79a55ef43fabab8):

$ git bz apply 1109868
Bug 1109868 - XUL popups with an anchor element should hide when the anchor loses its visibility and/or frame

Hide or move popups when the anchor changes
Apply? [yn] y

Applying: 
.git/rebase-apply/patch:628: trailing whitespace.
function waitForPanel(panel, event)  
warning: 1 line adds whitespace errors.
Traceback (most recent call last):
  File "/Users/past/src/git-bz-moz/git-bz", line 1788, in <module>
    do_apply(*args)
  File "/Users/past/src/git-bz-moz/git-bz", line 1170, in do_apply
    commits = rev_list_commits("HEAD^!")
  File "/Users/past/src/git-bz-moz/git-bz", line 203, in rev_list_commits
    raise RuntimeError("git rev-list didn't return a number of lines divisible by 3")
RuntimeError: git rev-list didn't return a number of lines divisible by 3

After using git-bz for a while I've noticed a number of files left in /tmp.
I think the bug is that git-bz:edit_template doesn't os.remove the
temporary file.

Here's the STR.

It can be seen from the STR, "git bz apply" creates the "commit-message-***" file locally as part of the imported commit, and then apply the virtual file unexpectedly. This caused an accidentally landing of extra commit-message.

I have the git mozreview stuff installed, so every patch somehow gets a line added to the end of the commit message like "MozReview-Commit-ID: I3m2BtlZc3b". It would be nice if any place we export a patch, such as when it is attached to a bug, or pushed via hg, that those would get removed.

I have a patch description that looks like:

Bug 12345 - whatever

Bug 60000 did something

This makes git bz attach complain about ambiguity, but it seems reasonable to use the one from the first line if there is ambiguity, or something.

Right now it links the bug url in the commit, but it should add "Bug NNNNNNN - " as a prefix to the first line, eg "Fix the foo; r=someone" should become "Bug 1234567 - Fix the foo; r=someone".

See https://hg.mozilla.org/try/rev/2df1c96f43bd for example.

Note that I have the following in my ~/.gitconfig:

[bz]
    add-url-method = "subject-prepend:Bug %d - "
    add-url-ignore-remote-commits = true

cc @amccreight

It would be nice to have a built-in way to disable any actual changes to Bugzilla, for use when testing why something is going wrong. The ideal way would be a fake server mode that would print out what is getting pushed to it, but something that just aborts before anything real happens might be okay, too. Right now, I just hack this up every time I need to debug something.

non-e doesn't seem very useful, and it would save some typing and errors.

As an example,

$ git bz apply 1177933
Bug 1177933 - Provide run script or mach command for eslint in mobile/android

$

applies neither of the two patches in the bug. I wonder if this is related to the use of reviewboard...

See mozilla/moz-git-tools#52

git bz apply actually calls git am to apply the patch, so if you are trying to apply a patch that is a raw diff without the other formatting niceties then you get a weird error about 'Patch format detection failed.'.

We could try to do some magic fallback to git apply if git am fails, but I think the better long term solution is to add a new git bz am command that uses git am, and make git bz apply actually use git apply. That will cause confusion for existing users but would be more consistent.

When using git bz apply and the bug attachments are mozreview requests, the applied patches don't have the right authorship: the dates are wrong, and the author name is the author email (as in, git log shows the Author as email <email>)

I tried filing a patch with a reviewer. Unfortunately, the person's bugzilla : name is actually a prefix of two (!) names and so git bz attach fails with a No Conclusive Match error from bugzilla.

It would be nice if it let you resolve the ambiguity, and perhaps even remember that resolution for next time so you don't have to keep doing it.

If the user selects abort, we don't catch the exception. It would be a little nicer if we caught the exception and did some kind of die() instead.

Apparently you can specify a bug number on the command line when attaching a patch, like so:
bz attach -e 12345 @

If the commit message for @ isn't Bug 12345, then it just slaps a new "Bug 12345 - " at the start of the commit message. It should instead report some kind of conflict for this. There's a tricky case where the commit message may contain a description with a bug number, but you still want to add a new bug number to the start, but maybe that's not a big deal.

I'm also not sure if anybody actually uses this bug number feature regularly.

To make add_url do something more useful, Add add-url-method = "subject-prepend:Bug %d -" to your gitconfig. This should be the default. I don't know who wants a random bugzilla URL inserted into their patch.

If user sets "Use experimental user interface" to "On", to benefit from the new modal UI, then attach gets broken:

Traceback (most recent call last):
File "/home/alex/codaz/Mozilla/moz-git-tools/git-bz", line 2563, in
do_attach(*args)
File "/home/alex/codaz/Mozilla/moz-git-tools/git-bz", line 1937, in do_attach
bug = Bug.load(handle)
File "/home/alex/codaz/Mozilla/moz-git-tools/git-bz", line 1463, in load
bug._load(bug_reference.id, attachmentdata)
File "/home/alex/codaz/Mozilla/moz-git-tools/git-bz", line 1203, in _load
etree.parse(response)
File "", line 38, in parse
cElementTree.ParseError: not well-formed (invalid token): line 7, column 91

It is often good to see the changes for patch #n so I have a better idea of who to ask for review/feedback and if I accidentally left a header include in that isn't used anymore etc. Good to just have a chance to review the patch right before it is attached.

I run git bz apply 1375969, and get the following exception. I don't know it's an issue on the tool or on the server.

Exception: REST error on GET to https://bugzilla.mozilla.org/rest/[email protected]: There is no user named 'emilio [email protected]'. Either you mis-typed the name or that user has not yet registered for a Bugzilla account.

Ehsan says that "git bz file -e 'Core/Component' ref" will create a new bug from a patch. I should add support for splitreviewer to it, so that the r=foo stuff is removed from the bug subject.

It would be convenient to be able to assign the bug to yourself when uploading a patch.

The basic feature would be adding an AssignedTo field to the file you edit for bz attach -e. There could be pre-filled in things for the current assignee, for assigning it to yourself, and for resetting it to the default.

There could also be more automatic behavior, like if there is no current assignee you assign it to yourself by default. This could still be commented out from the edit file if you don't want it, but it is the most common use case.

STR:

1. Create a patch with git mv
2. Attach a patch to bugzilla

Actual Results
No hg rename/move annotations in the patch on bugzilla

Expected Results
hg rename/move annotations.

For example, see https://bug1022594.bugzilla.mozilla.org/attachment.cgi?id=8472973

When I created the patch, I did:
git mv browser/components/loop/test/xpcshell/test_loopservice_get_loop_char_pref.js browser/components/loop/test/xpcshell/test_loopservice_loop_prefs.js
git mv browser/components/loop/test/mochitest/browser_mozLoop_charPref.js browser/components/loop/test/mochitest/browser_mozLoop_prefs.js

These haven't been recorded.

When using git bz attach -e SHA, I can uncomment one of the following lines:

#Review: :vingtetun
#Review: [email protected]
#Review: :me+

but with no effect. I'd love to be able to request a review from git bz attach, or carry over a previous r+.

|git bz attach -e HEAD~8..| was hanging for several minutes with no output -- turns out it was checking if it could add a URL to a commit, and running |git branch --contains -r | to "see if it was pushed anywhere". Though potentially a good warning to have, this command takes 5+ minutes on my repository, which is tracking 8006 remote branches.

Additionally, it is somewhat backwards that we will, by default, rewrite commits to insert bug #s, but only prompt before doing it if some convenience check fails.

When Bug.load() fetches patches in do_attach(), it does so with attachment_data=False. This means the 'data' element isn't present in the attachment, so _process_reviewboard_request() dies with KeyError: 'data'.

I think an easy workaround here is to just ignore MozReview patches if we don't get the 'data' element, though I believe that means you can't obsolete a MozReview patch by using 'git bz attach'. I'm not sure how often that would actually come up though. If there's a better solution here, I'm all for it.

I post a patch via git bz attach -e with a reviewer set, and got the following exception.

Traceback (most recent call last):
  File "/Users/tlin/Projects/moz-git-tools/git-bz", line 1790, in <module>
    do_attach(*args)
  File "/Users/tlin/Projects/moz-git-tools/git-bz", line 1425, in do_attach
    attach_commits(bug, commits, edit=global_options.edit)
  File "/Users/tlin/Projects/moz-git-tools/git-bz", line 1354, in attach_commits
    bug.create_patch(description, comment, filename, patch, obsoletes=obsoletes, patch_flags=patch_flags)
  File "/Users/tlin/Projects/moz-git-tools/git-bz", line 861, in create_patch
    self.server.auth.rest_request('POST', 'bug/%s/attachment' % self.id, data=o)
  File "/Users/tlin/Projects/moz-git-tools/git-bz-moz/bzauth.py", line 149, in rest_request
    method, url, j['message']))
Exception: <exception str() failed>

I then print the return JSON object, and got the following.

{u'code': 32000, u'message': u"David Baron :dbaron: \u231a\ufe0fUTC-5 (busy February 1-10) <[email protected]> is not currently accepting 'review' requests.", u'documentation': u'http://www.bugzilla.org/docs/tip/en/html/api/', u'error': True}

I'll be nice to have a message saying that the reviewer doesn't accept the review requests.