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

This patch makes all merge log messages of the form:

  Merge branch XXXX into YYYY

Regardless of whether YYYY is master or not.

"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?

Signed-off-by: Andy Parkins <redacted>
---
 builtin-fmt-merge-msg.c |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
index 87d3d63..99edb75 100644
--- a/builtin-fmt-merge-msg.c
+++ b/builtin-fmt-merge-msg.c

@@ -331,10 +331,7 @@ int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix)
 			printf(" of %s", srcs.list[i]);
 	}
 
-	if (!strcmp("master", current_branch))
-		putchar('\n');
-	else
-		printf(" into %s\n", current_branch);
+	printf(" into %s\n", current_branch);
 
 	if (merge_summary) {
 		struct commit *head;

-- 
1.4.4.1.g3ece-dirty

On Thu, 14 Dec 2006, Han-Wen Nienhuys wrote:

Johannes Schindelin escreveu:

quoted

Hi,

On Thu, 14 Dec 2006, Andy Parkins wrote:

quoted

"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?

Disagree: I have two principal branches, master and stable/2.10.  I don't see
why the latter should get different commit messages.

I also agree to disagree.  "master" is maybe the default branch, but it 
is not so special to deserve a different message than any other branch.

On Thu, Dec 14, 2006 at 03:19:44PM +0000, Andy Parkins wrote:

This patch makes all merge log messages of the form:

  Merge branch XXXX into YYYY

Regardless of whether YYYY is master or not.

"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?

Why not drop the "into YYYY" part for everyone else?  I don't find
it useful at all, and is just confusing if I merge to a temporary
branch and then pull that into master later.

John
-- 
John W. Linville

Hi,

Johannes Schindelin wrote:

On Thu, 14 Dec 2006, Andy Parkins wrote:

quoted

"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.

Jérôme

Hi,

On Thu, 14 Dec 2006, Andy Parkins wrote:

Making "master" special rather than simply a default means git is 
dictating policy.  It isn't git's place to decide what my branches are 
called, especially as it is git itself that lets me choose freely to 
begin with.

Fine. I don't give a flying fly. And if -- by making this and related 
changes -- new users find it even harder to start with Git, I will ignore 
any complaints. I mean, this is yet something new in an almost-everyday 
message that the user has to get used to.

Ciao,
Dscho

Han-Wen Nienhuys escreveu:

Johannes Schindelin escreveu:

quoted

Hi,

On Thu, 14 Dec 2006, Andy Parkins wrote:

quoted

"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?

Disagree: I have two principal branches, master and stable/2.10.  I don't see
why the latter should get different commit messages.

Note that this also confused my codeveloper (who is rather enamoured bzr), who
was wondering what the other branch was in case of 

  Merge branch 'master' of ssh+git://git.sv.gnu.org/srv/git/lilypond


Wouldn't it be better to mention the id of the local repository too? 

  Merge branch 'master' of ssh+git://git.sv.gnu.org/srv/git/lilypond into 
  'master' of 'hanwen@xs4all.nl'

this would give more information when these commit messages get pushed to 
someone else.

-- 

quoted

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?

You're correct; but we're talking about branch names not program names.

And the analogy is flawed.  I don't want git to be called guitar, however I'd 
be very upset if I got
  
 $ mv git guitar
 Error: git is conventionally called guitar


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE

Hi,

On Thu, 14 Dec 2006, Han-Wen Nienhuys wrote:

Wouldn't it be better to mention the id of the local repository too? 

  Merge branch 'master' of ssh+git://git.sv.gnu.org/srv/git/lilypond into 
  'master' of 'hanwen@xs4all.nl'

this would give more information when these commit messages get pushed 
to someone else.

And why not put your address and birthday in there, too?

Frankly, it does not matter. In my private git repository I see that I 
often merged from this machine to that machine, criss-crossing often. It 
does not buy me anything to even know _where_ I got it from.

Besides, the information you are most likely looking for is the committer, 
which is recorded anyway.

The single most useful information in the Merge message is the name of the 
branch I merged, since it is more often than not a topic branch, which is 
aptly named.

Ciao,
Dscho

On Thursday 2006, December 14 20:41, Junio C Hamano wrote:

However, the fmt-merge-message was designed so for a very
practical reason --- to keep Merge commit log messages Linus
makes in the kernel repository short and readable.

I'm only after consistency; how about the reverse solution: drop the "into" 
completely?


Andy
-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE

On Thursday 2006 December 14 15:29, Johannes Schindelin wrote:

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

While there might _usually_ be a principal branch; the special casing is 
_always_ hard coded.

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?

You're correct; but we're talking about branch names not program names.  
Making "master" special rather than simply a default means git is dictating 
policy.  It isn't git's place to decide what my branches are called, 
especially as it is git itself that lets me choose freely to begin with.

Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE

Andy Parkins [off-list ref] writes:

"master" shouldn't get special treatment

In principle yes.

However, the fmt-merge-message was designed so for a very
practical reason --- to keep Merge commit log messages Linus
makes in the kernel repository short and readable.

When your workflow is heavily based on merges from topics to
more than one maintenance tracks (say, 'maint' and 'master') and
the policy is to keep older maintenance tracks to be subsets of
newer maintenance tracks (e.g. changes applicable to an older
maintenance track are first merged into 'maint' and then 'maint'
is merged into 'master'), being able to see the patchflow is
sometimes handy [*1*].

I do not have issues against making git-status to always note
which branch the commit is going to be made, though.


[Footnote]

*1* Right now we do not have --only-merges option to log family,
so I use "show-branch maint master | grep '^ *-'" instead to get
this information.

Jerome Lovy [off-list ref] writes:

Johannes Schindelin wrote:

quoted

On Thu, 14 Dec 2006, Andy Parkins wrote:

quoted

"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.

Johannes Schindelin wrote:

On Thu, 14 Dec 2006, Han-Wen Nienhuys wrote:

quoted

Wouldn't it be better to mention the id of the local repository too? 

  Merge branch 'master' of ssh+git://git.sv.gnu.org/srv/git/lilypond into 
  'master' of 'hanwen@xs4all.nl'

this would give more information when these commit messages get pushed 
to someone else.

And why not put your address and birthday in there, too?

Frankly, it does not matter. In my private git repository I see that I 
often merged from this machine to that machine, criss-crossing often. It 
does not buy me anything to even know _where_ I got it from.

Besides, the information you are most likely looking for is the committer, 
which is recorded anyway.

The single most useful information in the Merge message is the name of the 
branch I merged, since it is more often than not a topic branch, which is 
aptly named.

By the way, I run git with merge.summary=true, and it is very nice and
usually shows the correct thing... but because git doesn't mark branching
points in any way sometimes under feature branch header there are changes
not related to given topic, but which were on given branch; the
fast-forward case I think.

That said, I'm all for not having "master" branch special-cased, besides
having it default name for branch in git-init-db.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

torsdag 14 december 2006 18:42 skrev John W. Linville:

On Thu, Dec 14, 2006 at 03:19:44PM +0000, Andy Parkins wrote:

quoted

This patch makes all merge log messages of the form:

  Merge branch XXXX into YYYY

Regardless of whether YYYY is master or not.

"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?

Why not drop the "into YYYY" part for everyone else?  I don't find
it useful at all, and is just confusing if I merge to a temporary
branch and then pull that into master later.

Or just drop both the from, into and repo names.. A commit may come from a 
certain repo, buy you would never know since it may have been pulled there 
rather than committed, so the merge message is misleading and if the merge 
was a fast forward you wouldn't see a merge message at all.

To make everybody happy, the .git/config could contain a template that states 
the project policy on merge commits.

Obviously the person executing the merge is free to amend the merge message, 
insertering synthetic commits or whatever he/she sees fit.

Johannes Schindelin escreveu:

Hi,

On Thu, 14 Dec 2006, Andy Parkins wrote:

quoted

"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?

Disagree: I have two principal branches, master and stable/2.10.  I don't see
why the latter should get different commit messages.

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Hi,

On Thu, 14 Dec 2006, Han-Wen Nienhuys wrote:

Johannes Schindelin escreveu:

quoted

Hi,

On Thu, 14 Dec 2006, Andy Parkins wrote:

quoted

"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?

Disagree: I have two principal branches, master and stable/2.10.  I 
don't see why the latter should get different commit messages.

Well, in your case I would even more strongly argue that "Merging into 
master" bears no more information than "Merging", since "master" is too 
generic a name. Since "stable/2.10" is more specific, the same reasoning 
does not apply here.

Ciao,
Dscho

Hi,

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?

Ciao,
Dscho