| Age | Commit message (Collapse) | Author |
|---|
|
https://bugzilla.gnome.org/show_bug.cgi?id=673828
|
|
Was failing to retrieve the bugzilla login cookie due to the fact
that it's stored with a host_key of '.bugzilla.redhat.com'
https://bugzilla.gnome.org/show_bug.cgi?id=673826
|
|
Cookie jar got migrated from ~/.gnome2/epiphany to ~/.config/epiphany
https://bugzilla.gnome.org/show_bug.cgi?id=676241
|
|
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
|
|
""" not """"
|
|
Fix a double addition of the commit message, and add a comment
pointing out that the exact string is checked by git.gnome.org.
|
|
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.
|
|
If the editor uses the terminal, the missing _interactive=True will
cause things to hang.
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
|
|
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>
|
|
Pass all the necessary fields to merge_default_fields_from_dict().
|
|
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".
|
|
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
|
|
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
|
|
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>.
|
|
|
|
All the logic to add the user to the cc: list on the bug is done in the
web page for show_bug.cgi and not on the client side, so the option
"Automatically add me to the CC list of bugs I change" in the user's
preferences is not honored. Since that preference defaults to Always
and users will very typically want to see further traffic on their patches,
just always request the user to be added to the Cc.
The main downside to this is that we do another round trip to the server
when creating and attachment, and also potentially create more bug mail.
https://bugzilla.gnome.org/show_bug.cgi?id=663800
|
|
|
|
|
|
If the data that we are writing into the template ends includes
non-ASCII data, it will need to be encoded as UTF-8 before writing
the template file. Fix from Luca Bruno.
https://bugzilla.gnome.org/show_bug.cgi?id=657716
|
|
If 'git bz file' is used with a commit message that contains a
bug reference, prompt before filing again.
https://bugzilla.gnome.org/show_bug.cgi?id=624461
|
|
Use Bug.legal_values({ product_id: <id> }) to find out legal
component values in a way that works on older Bugzilla like the
bugzilla.gnome.org 3.4.
This requires finding out the product_id first, which is fast
with new bugzilla, but requires a slow fallback on older bugzillas;
we cache positive hits for product IDs in our cache.
https://bugzilla.gnome.org/show_bug.cgi?id=654693
|
|
eg
git bz components -b bugzilla.gnome.org gnome-shell
or just
git bz components
if you have defaults configured
https://bugzilla.gnome.org/show_bug.cgi?id=654693
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=657723
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=632006
|
|
git prefers $VISUAL to $EDITOR. Most of the time. Fortunately we can
just ask git what editor to use rather than trying to figure it out
ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=654396
|
|
The cookies were being pulled out of Sqlite were Unicode, which
caused the entire HTTP buffer to be Unicode. When concatenating
non-ascii string instances (as would be returned from e.g. git),
things blew up.
Ensure the cookie data is UTF-8 str, and also set our content
encoding explicitly to UTF-8.
https://bugzilla.gnome.org/show_bug.cgi?id=633729
|
|
Should have been 'git commit --amend'. Noticed by Matěj Cepl.
|
|
In Python 2.7 xmlrpclib was changed to use httplib.HTTP[S]Connection
instead of the deprecatede httplib.HTTP[S]. This broke our
xmlrpclib.Transport subclass which overrode make_connection().
For compatibility with old and new Python, switch to subclassing
Transport and SafeTransport separately, with a mixin to add cookies.
https://bugzilla.gnome.org/show_bug.cgi?id=628731
|
|
Allow specifying the default value for whether URLs are added via
a new git config variable. The -u/--add-url and -n/--no-add-url
override this value.
Based on a patch by Xavier Claessens <xclaesse@gmail.com>
|
|
using commit.subject
By mistake, the code was discarding the description after parsing it out from
the edit buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=628455
|
|
In git_run, interactive was initialized twice. Fix from
Felipe Contreras <felipe.contreras@gmail.com>.
|
|
Add documentation for 'path', 'auth-user', and 'auth-password'
|
|
Instead of using authuser and authpwd, spell out auth_user and
auth_password (as was already done in some places.) This changes
the config options to auth-user and auth-password.
|
|
Code to handle parsing a base-path out of the URL would get confused
when given an URL without a path or an URL without a hostname. Catch
those cases.
|
|
|
|
Since Python 2.5, pysqlite2 has been included in the Python standard
library with the name sqlite3.
https://bugzilla.gnome.org/show_bug.cgi?id=621715
|
|
The example url in the section "Ways to refer to a bug" was causing
asciidoc to emit invalid xml (by closing a docbook ulink tag before the
closing semicolon for a > replacement giving ></ulink>;) which
meant that xmlto could not then produce a man page. Quoting the url
seems to workaround this issue.
asciidoc version was 8.4.4
https://bugzilla.gnome.org/show_bug.cgi?id=621580
|
|
|
|
Rather than taking empty or unknown input as a "no", just
reprompt. I don't think the default value is obvious enough
for people to actually figure it out and rely on it, so we might
as well add extra robustness to accidental input.
|
|
Python adds a space character between consecutive calls to
print when the first print doesn't end in a newline. To
avoid problems with this, use <file>.write() rather than
print when:
* We might be printing something empty
* The newline after the line is added via echoed user
input on the terminal
Tracked down by William Jon McCann <william.jon.mccann@gmail.com>
|
|
|
|
Chromium and Google Chrome have the same basic way of storing
cookes, but different config paths. Add a google-chrome browser
option with the correct config path for Google Chrome.
Based on a patch by Eitan Isaacson <eitan@monotonous.org>
|
|
When they moved to webkit as the browser engine, epiphany changed the location
of their cookies database, but the format remained the same. This patch adds
support for the new location, but falls back to the old location if the new one
doesn't exist.
https://bugzilla.gnome.org/show_bug.cgi?id=609668
|
|
The code that was supposed to handle
'See Mozilla bug http://bugzilla.mozilla.org/show_bug.cgi?...'
as a cross reference was also detecting
'See
https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference/JS_MaybeGC
https://bugzilla.gnome.org/show_bug.cgi?id=614725'
As a cross-reference. Fix by requiring the "intervening words" not
to have a : or / in them, since "See <url>" is clearly standalone
and something with a : or a / in it is probably an URL.
Reported by Adel Gadllah
https://bugzilla.gnome.org/show_bug.cgi?id=619328
|
