Hi y'all,
With the pending git migration upon us,is this also the right time to think about naming conventions for git branches or is there nu such a need? I can imagine that a branch aimed at fixing a bug could be named B12345, or something like that. Or are 'descriptive' names good enough? One reason to have naming conventions is that it would make it easier in the future to run scripts to collect stats on particular branches. That would be much harder in a complete freetext environment.
Best,
Diederik
On Wed, Mar 21, 2012 at 14:17, Diederik van Liere dvanliere@gmail.com wrote:
I can imagine that a branch aimed at fixing a bug could be named B12345, or something like that.
IMHO, the extra 2 letters are worth the extra space used. So, make it bug12345 instead.
-Jeremy
On Wed, Mar 21, 2012 at 2:17 PM, Diederik van Liere dvanliere@gmail.com wrote:
Hi y'all,
With the pending git migration upon us,is this also the right time to think about naming conventions for git branches or is there nu such a need? I can imagine that a branch aimed at fixing a bug could be named B12345, or something like that. Or are 'descriptive' names good enough? One reason to have naming conventions is that it would make it easier in the future to run scripts to collect stats on particular branches. That would be much harder in a complete freetext environment.
Having a bug number is useful and gives an immediate place to look for information. git-review uses the local branch name as the "Topic" so it's helpful for grouping things relating to a single bug in Gerrit.
For features or other random things that don't have a specific bug, I prefer being nice and descriptive. Something like "config-mgmt-overhaul" or "new-feature-foobar" are clear. Something like "ui-fix" isn't.
I think we should use the same naming conventions like we do for message keys--all lowercase and using hyphens rather than spaces or underscores.
Other than the branch/tag names for core, I don't think we necessarily need strong guidelines here--common sense should suffice for now.
When in doubt: be verbose!
-Chad
To me this looks like a light-weight naming convention, awesome! D
On Wed, Mar 21, 2012 at 2:25 PM, Chad innocentkiller@gmail.com wrote:
On Wed, Mar 21, 2012 at 2:17 PM, Diederik van Liere dvanliere@gmail.com wrote:
Hi y'all,
With the pending git migration upon us,is this also the right time to think about naming conventions for git branches or is there nu such a need? I can imagine that a branch aimed at fixing a bug could be named B12345, or something like that. Or are 'descriptive' names good enough? One reason to have naming conventions is that it would make it easier in the future to run scripts to collect stats on particular branches. That would be much harder in a complete freetext environment.
Having a bug number is useful and gives an immediate place to look for information. git-review uses the local branch name as the "Topic" so it's helpful for grouping things relating to a single bug in Gerrit.
For features or other random things that don't have a specific bug, I prefer being nice and descriptive. Something like "config-mgmt-overhaul" or "new-feature-foobar" are clear. Something like "ui-fix" isn't.
I think we should use the same naming conventions like we do for message keys--all lowercase and using hyphens rather than spaces or underscores.
Other than the branch/tag names for core, I don't think we necessarily need strong guidelines here--common sense should suffice for now.
When in doubt: be verbose!
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
If someone wants to fold these into [[mw:Git/Workflow]] or another appropriate place in the Git docs, please feel free.
-Chad
On Wed, Mar 21, 2012 at 2:42 PM, Diederik van Liere dvanliere@gmail.com wrote:
To me this looks like a light-weight naming convention, awesome! D
On Wed, Mar 21, 2012 at 2:25 PM, Chad innocentkiller@gmail.com wrote:
On Wed, Mar 21, 2012 at 2:17 PM, Diederik van Liere dvanliere@gmail.com wrote:
Hi y'all,
With the pending git migration upon us,is this also the right time to think about naming conventions for git branches or is there nu such a need? I can imagine that a branch aimed at fixing a bug could be named B12345, or something like that. Or are 'descriptive' names good enough? One reason to have naming conventions is that it would make it easier in the future to run scripts to collect stats on particular branches. That would be much harder in a complete freetext environment.
Having a bug number is useful and gives an immediate place to look for information. git-review uses the local branch name as the "Topic" so it's helpful for grouping things relating to a single bug in Gerrit.
For features or other random things that don't have a specific bug, I prefer being nice and descriptive. Something like "config-mgmt-overhaul" or "new-feature-foobar" are clear. Something like "ui-fix" isn't.
I think we should use the same naming conventions like we do for message keys--all lowercase and using hyphens rather than spaces or underscores.
Other than the branch/tag names for core, I don't think we necessarily need strong guidelines here--common sense should suffice for now.
When in doubt: be verbose!
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Chad wrote:
Having a bug number is useful and gives an immediate place to look for information. git-review uses the local branch name as the "Topic" so it's helpful for grouping things relating to a single bug in Gerrit.
Additionally git-review try to guess a topic name. For example it might detect a bug number and use that to forge the topic branch.
On Wed, Mar 21, 2012 at 11:17 AM, Diederik van Liere dvanliere@gmail.com wrote:
With the pending git migration upon us,is this also the right time to think about naming conventions for git branches or is there nu such a need?
Yup, there is. My bias right now, though, is that we have one single convention, which is to prefix our branch names with the year (e.g. "2012/bug12345"), and not overthink it too much past that. That lets us have an implicit hierarchy that naturally fades to irrelevance over time, since, for example, it's unlikely that in 2017 most people will care about anything under "2012/*", so if we decide on something we regret, we've limited the damage.
We don't have to make *all* branches like that. So, for example, we can keep using the same convention for all of the branches that survived the svn->git migration (e.g. REL1_17, REL1_18, REL1_19), but new work branches should almost certainly follow the year prefix scheme.
Rob
2012/3/21 Diederik van Liere dvanliere@gmail.com:
Hi y'all,
With the pending git migration upon us,is this also the right time to think about naming conventions for git branches or is there nu such a need? I can imagine that a branch aimed at fixing a bug could be named B12345, or something like that. Or are 'descriptive' names good enough? One reason to have naming conventions is that it would make it easier in the future to run scripts to collect stats on particular branches. That would be much harder in a complete freetext environment.
In the few commits i did until now, i usually did called it something like "bug_31817_add_bdi_to_allowed_tags". Nobody complained yet. I'm OK with "2012/bug_31817_add_bdi_to_allowed_tags", too, or anything else that will be decided.
When i use `git review -d' on a change that was in the aforementioned branch, another branch called "review/amire80/bug/31817" is created, so i suppose that Gerrit identified the bug number (or maybe somebody did it manually and i missed it). I don't quite understand why two branches are created for pretty much the same thing. Maybe i should create a branch called "review/amire80/bug/31817" in the first place?
Or maybe i shouldn't use `git review -d' at all?
And, there's also the issue of several branches per one bug, so it's possible that it's not enough.
-- Amir Elisha Aharoni
On Wed, Mar 28, 2012 at 1:58 AM, Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
When i use `git review -d' on a change that was in the aforementioned branch, another branch called "review/amire80/bug/31817" is created, so i suppose that Gerrit identified the bug number (or maybe somebody did it manually and i missed it). I don't quite understand why two branches are created for pretty much the same thing. Maybe i should create a branch called "review/amire80/bug/31817" in the first place?
Or maybe i shouldn't use `git review -d' at all?
No, this is expected behavior. git review -d creates branches with this naming convention, the only reason it's weird is because you're downloading yuor own change rather than someone else's.
Roan
wikitech-l@lists.wikimedia.org