Enforces "Topic" too strong (uses bug number mentioned in summary instead of branch name)

Bug #1130330 reported by Andre Klapper
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
git-review
New
Undecided
Unassigned

Bug Description

Upstreaming from https://bugzilla.wikimedia.org/show_bug.cgi?id=35967

Steps to reproduce:
1. Local checkout of mediawiki/core.git
2. git co -b 2012/foobar
3. (edit files)
4.
git commit; with a message that doesn't mention a bug number in the first 5
lines and somewhere a long the line it makes a mention of 3 bugs (not even in
parentheses), just like "foo bar bug 123, 456 (and bug 789 also)".
5. It will then have submitted it as topic: bug/123 instead of 2012/foobar.

---
I like the automatic topic but it should not happen if:
* I have a good local branch name already
* Did not mention the bug on the first line
* It wasn't the only bug mentioned

Workaround: Manually specify a topic on `git review`

Revision history for this message
Marcin Cieślak (saperski) wrote :

What do you think should be the desired behaviour?

Currently it checks:

1) -t option (if yes, it uses that)
2) if local branch is named "review/%s/%s" then it uses the last string component
3) searches for bug or lp number
4) searches for blueprint ("bp") number
5) uses local branch name as it is

When checking out the change with "-d", local branch gets set to "review/<author>/<change-number>" or "review/<author>/<change-number>-patch<patchset-number>"

Revision history for this message
Timo Tijhof (krinklemail) wrote :

I don't have any preference for the desired behaviour. Just as long as it doesn't override my local branch name, causing me having to have to think twice about whether I used the word "bug" in my commit message and remember to pass -t, which feels silly.

Perhaps restrict #3 and #4 to the first line (or first few lines up until the first line break, to be conforming with Git/Gerrit/GitHub's concept of commit message "subject" vs. "body"), so that it isn't influenced by a mention of "bug" later in the commit message body.

It is only for creating a better default topic name, shouldn't do any harm if it doesn't auto-guess it. Only good (in that is prevents false positives such as the one in the opening post where it isn't a suggestion but actually overriding a valid and intended topic branch name).

Personally I'd rather only have #1 and #5 (and #2, which is like #5) and delete #3 and #4 entirely (I'd never use them, and when I do it is by accident and regret it the minute I find out). I name my branches for a reason so unless I override it with -t that's what I want, regardless of what words may appear in my commit message.

But, I do see the usefulness in naming them automatically as a convenience for users who aren't in the habit of properly branching lcoally, so maybe only do #3 and #4 if the local branch name indicates this kind of user (e.g. where branch name is the name of gerrit/HEAD (e.g. "master") or "(no branch")).

Anyhow, whether restricting it to the first few lines or to non-topic branch names or some other clever approach, I just want to not have to use -t <topic> or push HEAD:refs/for/master/<topic> when using a fine topic name as branch name.

Revision history for this message
Marcin Cieślak (saperski) wrote :

The problem is this:

Except for the "detached HEAD" mode, there is always some local branch name. How do we know which one is good so you don'toverride it when setting a bug number?

Personally, I am in favour of dropping this feature altogether. Only -t is enough to me and empty topics are not necessarily bad.

But I undestand people are using bug/XXX and bp/XXX heavily in some projects.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.