Naming scheme for branches which will not be merged.

[Artur Malabarba]

2014-12-11 17:21 GMT+00:00 Stefan Monnier >
> Maybe we should decide of a particular branch-naming scheme which states
> clearly that the branch won't be merged into master (it will be
> applied as a brand new patch with a brand new commit message).

I agree with Stefan on this.

I find that the most convenient way of working on something while
getting feedback is to push it to a branch in origin. For this
specific purpose a branch which is not meant to be merged has a few
advantages over “real” branches.

We can develop without worrying about the ChangeLog file.
Each commit doesn't necessarily have to be a full change, which
naturally lends itself to the workflow of this list where diffs
commonly incite feedback which leads to small changes.
Commit messages don't have to follow any convention. If you make a
short commit to fix a typo, you can just say “Typo” and move on.
However, they should still be useful messages!

Once this branch is given as finished, the creator (or anyone else,
really), turns into one (or several) proper commit(s). This is when we
write real changelog/commit messages. How this is done is irrelevant,
you can use rebase+squash+merge or manually apply a patch on master.

The two questions I can think of are

What naming scheme should we use? Either prefix the branch name with
something really obvious, like “dont-merge/BRANCH-NAME”, so that
people who unaware of this convention don't make that mistake. Or
prefix it with any of the usual words that denote in-development, such
as “dev/BRANCH-NAME”.
Should the creator of the branch add his/her username to it? i.e.
“dont-merge/malabarba/BRANCH-NAME”.