Subject: Re: [PATCH] "master" should be treated no differently from any other branch

From: Junio C Hamano <[email-masked]>
Date: Fri, 15 Dec 2006 13:55:10 -0800

Jerome Lovy <[email-masked]> writes:

> Johannes Schindelin wrote:
>> On Thu, 14 Dec 2006, Andy Parkins wrote:
>>
>>> "master" shouldn't get special treatment; making different log
>>> messages based on the name of the branch is bad form.  What if a
>>> user likes "my/master" or "my/head" as their master branch?
>>
>> I do not agree. There is usually a principal branch, where you
>> collect the topics, and you do want to treat that special. As for
>> the name: better have a convention here than configurability. You
>> would not want "git" to be called "guitar" for some users, just
>> because they happen to like that name more, either, right?
>
> because I like the pattern framework described in the book "Software
> Configuration Management Patterns", I like to use "mainline" instead
> of "master", for example.

Tough.  Like it or not, 'master' has been the name of the
default branch since very early days of git (May 30, 2005).

I think you guys are barking up the wrong tree.  I do not agree
it is wrong to treat the principal branch (or branches, such as
my 'master' and 'maint', or Jeff's 'ALL' and 'upstream') in a
different way from other branches.

Quite the opposite.  It is a wonderful thing for something like
fmt-merge-message.

The recommended workflow when you have topic branches is to cook
new things in the topics and merge them into principal branches,
and never merge the other way or across topics unless you
absolutely need to (i.e. the topic's evolution depends on
something new in your principal branches or another topic).  So
merging into your principal branch is a normal event and giving
short message makes tons of sense, while merging into a topic is
an abnormal situation that warrants "into this-topic" along with
an explanation why that unusual cross merge was needed.

What we could improve is to allow people to use different names
other than 'master' for their principal branches, to help use of
words like 'mainline' and 'upstream'.  We can have a new
configuration under "branch.*" namespace to mark branches that
tells fmt-merge-msg to drop "into branch" part from its output.

When you have more than one principal branches, it may be useful
be able to tell which principal branch was merged into with a
particular merge, and in such a situation, you may want your
config to tell fmt-merge-msg not to drop "into branch" for any
branch.

On this "master is not special" topic, I would accept the
'status' patch that always makes it to say "on this branch" for
all branches, but this is not because 'master' is not special.

Committing on principal branches and committing on topic
branches both happen as a normal event, and I think it is not
unusual to have more than one principal branches in an advanced
usage scenario.  It is very prudent thing to remind the user
what branch he is on, so that he can tell he is about to make a
commit on a wrong branch.