summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Support for editing attachment flags.Philippe Normand2015-02-272-22/+122
| | | | | | | | | | | | | | | | | | | | | | | | One has to first define the available flags for the bugtracker used. The only way I found is to look at the source of the bugtracker "Create New Attachment" page. Examples of use of a review: flag below. Self-review would be: review: + Requesting a review from a specific person would look like: review: ? joe@example.com To request review from a specific person as shown above, the requesteeable git-bz option of the flag has to be set to true like: git config bz-tracker.bugzilla.mozilla.org.attachment-flag.review.requesteeable true (Patch includes fixes by Owen Taylor <otaylor@redhat.com>) https://bugzilla.gnome.org/show_bug.cgi?id=602406
* Handle further git exceptions in do_attach()Philip Withnall2015-02-271-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This improves validation of attach arguments. Previously, the command: git bz attach 741345 would result in the crash: fatal: ambiguous argument '741345': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' Traceback (most recent call last): File "/home/philip/.local/bin/git-bz", line 2472, in <module> do_attach(*args) File "/home/philip/.local/bin/git-bz", line 1830, in do_attach commits = get_commits(commit_or_revision_range) File "/home/philip/.local/bin/git-bz", line 233, in get_commits commits = rev_list_commits(commit_or_revision_range) File "/home/philip/.local/bin/git-bz", line 205, in rev_list_commits output = git.rev_list(*args, **kwargs_copy) File "/home/philip/.local/bin/git-bz", line 192, in f return git_run(command, *args, **kwargs) File "/home/philip/.local/bin/git-bz", line 174, in git_run raise CalledProcessError(process.returncode, " ".join(to_run)) subprocess.CalledProcessError: Command 'git rev-list --pretty=format:%s 741345' returned non-zero exit status 128 Now it prints an error gracefully. https://bugzilla.gnome.org/show_bug.cgi?id=742371
* Support FF3 and Google Chrome on MacYawar Amin2015-02-261-3/+14
| | | | | | | | | | Modify cookie getter functions to find the directories where the browser cookies are stored on Mac OS X. Applied with minor changes. See also: http://www.chromium.org/user-experience/user-data-directory https://bugzilla.gnome.org/show_bug.cgi?id=738337
* git bz apply: use consistent ordering of status and descriptionOwen W. Taylor2015-02-261-2/+2
| | | | | | | | | We ordered status and description differently in the initial display and in interactive mode. While the two modes are arguably a bit different in how you are using the information, it's better to use a consistent ordering so the user can learn where to look. https://bugzilla.gnome.org/show_bug.cgi?id=678152
* Show the status of all patches, not just accepted patchesOwen W. Taylor2015-02-261-2/+2
| | | | | | | It's a bit confusing to show some patch statuses, but not others. Switch to showing all statuses. https://bugzilla.gnome.org/review?bug=678152
* Show status for accepted patchesBastien Nocera2015-02-261-1/+6
| | | | | | | | | | When dealing with a patch series attached to one bug, it's hard to know which of the attachments have been marked as "accepted-commit_now" or "accepted-commit_after_freeze". This patch shows those statuses in the original apply question, and in the interactive application questions. https://bugzilla.gnome.org/show_bug.cgi?id=678152
* Improve handling of pushes with failuresOwen W. Taylor2015-02-261-7/+18
| | | | | | | | | | | | | | | | | A non-zero exit status from 'git push' doesn't necessarily mean that nothing was pushed - we should parse the output just as for a zero exit status. This requires adding a new option _ignore_exit_status to git_run(). For --dry, we can actually pay attention to the return code, but need to fix up previous logic where we returned None instead of a list of commits, and then tried to iterate over None. For clarity, let CalledProcessError throw through rather than special-casing a return of None. Inspired by a patch from Philip Withnall. https://bugzilla.gnome.org/show_bug.cgi?id=620668
* Make sure URLs are ascii when building HTTP requestOwen W. Taylor2015-02-261-1/+9
| | | | | | | | If an URL ends up with a unicode type, then that will force the body of the HTTP request to unicode; adding the raw bytes of the commit can then cause an encoding error. https://bugzilla.gnome.org/show_bug.cgi?id=745186
* Document bug references in commit messagesOwen W. Taylor2015-02-241-2/+23
| | | | | | | Add documentaton of recognized forms of bug references in commit messages, and explain the way that "See" suppresses bug reference identification. https://bugzilla.gnome.org/show_bug.cgi?id=708158
* Make search-for-substring idiomaticOwen W. Taylor2015-02-241-1/+1
| | | | | Though it didn't matter here, s.find(x) >= 0 is is better to write than s.find(x) > 0.
* Add a useful help string when the version is unknownOwen W. Taylor2015-02-241-0/+8
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=673828
* Add a configuration for bugzilla.redhat.comOwen W. Taylor2015-02-241-0/+5
| | | | | | | | | | | | | Specify that bugzilla.redhat.com is https - filing still won't work without specifying a default-version but we'll get a clean error message since it will now go through the XML-RPC interface and not be broken by the redirect (see bug 745100) Since the version on bugzilla.redhat.com is product specific, and we can't guess what products people will file bugs against, specifying a default version doesn't make sense. https://bugzilla.gnome.org/show_bug.cgi?id=673828
* Clarify usage of git-bz edit --fixOwen W. Taylor2015-02-241-0/+1
| | | | | Existing docs made it a bit hard to figure out how --fix works - list the usage explicitly.
* Set patch attachment status on creation for bugzilla.gnome.orgOwen W. Taylor2015-02-241-3/+1
| | | | | | | bugzilla.gnome.org now supports attachment status on attachment.cgi?action=insert. https://bugzilla.gnome.org/show_bug.cgi?id=745062
* Get attachment status editing working again for bugzilla.gnome.orgOwen W. Taylor2015-02-231-5/+11
| | | | | | Handle the changed name of the attachment status field; status on creation isn't supported with the current b.g.o code, so leave that as a FIXME for now.
* Fix conflict between urllib2 support and Bugzilla 4.2+ supportOwen W. Taylor2015-02-231-1/+1
| | | | | | | create_patch() now gets attachment.cgi to get a token - with the switch urllib2 this requires slightly different code. https://bugzilla.gnome.org/show_bug.cgi?id=725730
* Restore code to remember redirects now we are using urllib2Owen W. Taylor2015-02-231-1/+33
| | | | | | | | | | | | | | At times, we can make many separate requests. If we start off with a URL that bugzilla always redirects (say a HTTP URL), it's better to "get the message" and start using the target of the redirects. The code that used to do this was removed with the switch to urllib2. Add back equivalent code - it can be simplified at this point because bugzilla was changed to use 301 permanent redirects for HTTP => HTTPS redirects, and left using 302 requests for attachment redirects. https://bugzilla.gnome.org/show_bug.cgi?id=725730
* Switch from httplib to urllib2Jonas Danielsson2015-02-231-107/+53
| | | | | | | This simplifies the code and will auto-detect the users proxy settings and use those. https://bugzilla.gnome.org/show_bug.cgi?id=725730
* Move cache data to XDG_CACHE_HOMEPhilip Withnall2015-02-231-2/+17
| | | | | | So the cache file will now typically be ~/.cache/git-bz-cache. https://bugzilla.gnome.org/show_bug.cgi?id=674020
* Ensure all strings are internally handled as UnicodePhilip Withnall2015-02-231-8/+31
| | | | | | | | | | By treating all strings internally as Unicode (decoding them on input and encoding them on output), git commit messages which contain Unicode can be handled without getting UnicodeDecodeErrors. This works on Python 2 and 3. https://bugzilla.gnome.org/show_bug.cgi?id=684578
* Specify file encoding at the top of the Python filePhilip Withnall2015-02-231-0/+1
| | | | | | | Although none of the code or strings need it at the moment, it’s best to be explicit. https://bugzilla.gnome.org/show_bug.cgi?id=684578
* Ignore empty platform fields and change default for GNOME to emptyPhilip Withnall2015-02-191-1/+6
| | | | | | | As a follow up to commit 68256107, change the default platform for GNOME Bugzilla to the empty string, and ignore empty platform fields when uploading. This makes Bugzilla use the default value, which would be ‘Other’ or ‘All’ or whatever the product has set up.
* Change default platform for GNOME Bugzilla to ‘Other’Philip Withnall2015-02-191-0/+1
| | | | | | | | It was previously ‘All’, but this seems to have been removed for all products with the upgrade to Bugzilla 4.4. Change the default to ‘Other’, which is still present. https://bugzilla.gnome.org/show_bug.cgi?id=744319
* Update copy of COPYING from http://www.gnu.org/licenses/gpl-2.0.txtVille Skyttä2015-02-121-21/+20
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=721962
* Search for cookies for ".host" in addition to "host" from sqlite.Ville Skyttä2015-02-121-2/+2
| | | | | | At least bugzilla.redhat.com ones are stored like that. https://bugzilla.gnome.org/show_bug.cgi?id=673826
* Add a ‘REPORTING BUGS’ section to the man pagePhilip Withnall2015-02-121-0/+4
| | | | | | So that people know where to report git-bz bugs. https://bugzilla.gnome.org/show_bug.cgi?id=742370
* Retitle the ‘AUTHORS’ section in the man pagePhilip Withnall2015-02-121-2/+2
| | | | | | | Title it ‘AUTHORS’ rather than ‘Author’ to make it more in line with other man pages. https://bugzilla.gnome.org/show_bug.cgi?id=742370
* Add support for attaching patches on Bugzilla 4.2+Philip Withnall2015-02-121-0/+16
| | | | | | | | | | attachment.cgi requires a token field for Bugzilla 4.2 and later. (See https://bugzilla.mozilla.org/show_bug.cgi?id=703983) This token is not the same as the overall bug's token. So from we need to load attachment.cgi as a GET before every POST, which is a bit of a pain. https://bugzilla.gnome.org/show_bug.cgi?id=700502
* Make srcdir != builddir builds workOwen W. Taylor2013-09-061-2/+3
| | | | Add $(VPATH), correct paths
* Add a simple build system implementing GNOME Build APIColin Walters2013-09-062-1/+84
| | | | | | | | | | | | | See http://people.gnome.org/~walters/docs/build-api.txt This way I can easily add it to the gnome-ostree manifest and have it install into /usr, package people can do their thing, etc. This dead simple non-autotools configure/Makefile system is adapted from one I wrote for gtk-doc-stub. Note I also added a --disable-documentation flag since gnome-ostree doesn't have asciidoc.
* Fix applying non-ASCII plain diffsOwen W. Taylor2013-08-011-1/+1
| | | | | | | The code that applied plain diff tried to add a Unicode header to uninterpreted patch data. https://bugzilla.gnome.org/show_bug.cgi?id=687734
* Fix typo: Uncommment => uncommentOwen W. Taylor2013-02-141-1/+1
| | | | Pointed out by Dan Winship
* Add support for epiphany 3.6Bastien Nocera2012-08-071-3/+7
| | | | | | Cookie jar got migrated from ~/.gnome2/epiphany to ~/.config/epiphany https://bugzilla.gnome.org/show_bug.cgi?id=676241
* attach: Obsolete patches with the same subjectJasper St. Pierre2012-03-132-1/+11
| | | | | | | | | For plain 'git bz attach', always obsolete existing patches if they have the same subject as the commit being attached. For 'git bz attach -e', make this the default. https://bugzilla.gnome.org/show_bug.cgi?id=671941
* apply: fix typoOwen W. Taylor2012-03-011-1/+1
| | | | """ not """"
* apply: Fix addition of 'need commit message' stringOwen W. Taylor2012-03-011-1/+2
| | | | | Fix a double addition of the commit message, and add a comment pointing out that the exact string is checked by git.gnome.org.
* apply: ask the user to double-check author and subjectOwen W. Taylor2012-03-011-0/+6
| | | | | | The author and subject might be wrong (especially the subject), when we make up a commit message for a plain patch, so ask the user to double check.
* apply: pass _interactive=True when running 'git commit --amend'Owen W. Taylor2012-03-011-2/+2
| | | | | If the editor uses the terminal, the missing _interactive=True will cause things to hang.
* apply: attempt to handle plain diffsDan Winship2012-03-012-2/+34
| | | | | | | | | If a bug has a plain diff (as opposed to git-format-patch output), prepend some minimal headers to it to get it into a format git-am will accept, and then make the user write a commit message for it before proceeding. https://bugzilla.gnome.org/show_bug.cgi?id=657558
* apply: add --continue/--skip/--abortDan Winship2012-03-012-45/+128
| | | | | | | | | | | Rather than failing completely when git-am fails to apply a patch, write out our current state to git-am's temporary directory, and then tell the user to use "git bz apply --continue/--skip/--abort" after handling the merge failure. When the user uses one of those options, read back our state, pass the flag on to git-am, and (assuming git-am succeeds), continue with the next patch. https://bugzilla.gnome.org/show_bug.cgi?id=657558
* apply: add interactive optionDan Winship2012-03-012-10/+58
| | | | | | | | | | | | | Rather than asking whether or not to apply each patch individually, list all of the patches at once and allow the user to either apply all of them, apply none of them, or interactively choose which ones to apply (a la interactive rebasing). In addition to choosing which patches to apply, the interactive option also allows reordering the patches before applying, and choosing to apply committed or rejected patches. https://bugzilla.gnome.org/show_bug.cgi?id=657558
* apply: pass "-3" to git-amDan Winship2012-03-011-1/+1
| | | | | | | | | | Using 3-way merge makes it much more likely that the patch will apply correctly when the local tree is newer than the tree that the patch was generated from, and if the patch doesn't apply cleanly, git will leave a file with conflict markers rather than forcing you to reapply the patch manually. https://bugzilla.gnome.org/show_bug.cgi?id=657558
* Work around line-break problemsOwen W. Taylor2012-03-011-0/+1
| | | | | | | | | | | | | | | | | The two lines for the different versions of 'git bz edit' are treated by asciidoc as a single paragraph and line-wrapped. In theory, a + at the end of a line is a forced line-break with asciidoc, but in the manpage generation route, this doesn't work properly - the magic in a2x that is supposed to turn the asciidoc-br processing instruction into a line break doesn't work. (We aren't using a2x at the moment for the conversion, but no real reason to switch if it doesn't work better.) So, use a [verse] paragraph instead. This results in mis-indentation, but slightly better than the previous breakage. https://bugzilla.gnome.org/show_bug.cgi?id=670686
* Fix up documentation generation rulesOwen W. Taylor2012-03-011-0/+4
|
* Don't strip leading space from the commit bodyOwen W. Taylor2012-02-101-4/+15
| | | | | | | If we strip leading space from the body, we'll unindent the first line of the body, which could break aligment. Based on a patch by Stef Walter <stefw@gnome.org>
* Fix parameter mistake from last patchOwen W. Taylor2012-02-071-2/+2
| | | | Pass all the necessary fields to merge_default_fields_from_dict().
* Make setting default-product, default-component in tracker config workOwen W. Taylor2012-02-061-14/+30
| | | | | | Allow setting the default-product in the tracker config. This is possibly useful for something like bugzilla.redhat.com where many repositories share a product of "Fedora".
* Support pretty bugzilla links like https://bugzilla.gnome.org/12345Colin Walters2012-02-061-2/+14
| | | | | | | Ideally I'd like git-bz to know when a Bugzilla instance supports these, but here at least we'll try parsing them. https://bugzilla.gnome.org/show_bug.cgi?id=657361
* Allow setting bz.default-<field name>Owen W. Taylor2012-02-052-7/+40
| | | | | | | | | | | If you want to override something like the default version on a per-component basis, having to set that in the per-tracker configuration is unnatural and confusing. Allow setting bz.default-version instead. This is interpreted as overriding the existing configuration of default field values. Based on a patch from Dan Winship <danw@gnome.org> https://bugzilla.gnome.org/show_bug.cgi?id=651756
* Read bz.* git config upfrontOwen W. Taylor2012-02-051-38/+31
| | | | | | | Instead of making calls to git.config() as needed, read all of our options ahead of time into a dictionary initialized with defaults. Loosely based on a patch from Felipe Contreras <felipe.contreras@gmail.com>.
generated by cgit (git 2.34.1) at 2024-11-13 00:18:30 +0000