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

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

[Andy Parkins]

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 <andyparkins@gmail.com>
---
 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

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

[Johannes Schindelin]

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

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

[Han-Wen Nienhuys]

Johannes Schindelin escreveu:
> 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?

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

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

[Johannes Schindelin]

Hi,

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

> Johannes Schindelin escreveu:
> > 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?
> 
> 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

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

[Han-Wen Nienhuys]

Han-Wen Nienhuys escreveu:
> Johannes Schindelin escreveu:
>> 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?
> 
> 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.

-- 

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

[Johannes Schindelin]

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

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

[Jerome Lovy]

Hi,

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.

Jérôme

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

[Andy Parkins]

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

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

[Andy Parkins]

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

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

[Johannes Schindelin]

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

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

[John W. Linville]

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

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

[Nicolas Pitre]

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

> Johannes Schindelin escreveu:
> > 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?
> 
> 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.

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

[Robin Rosenberg]

torsdag 14 december 2006 18:42 skrev John W. Linville:
> 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.

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.

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

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> 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.

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

[Andy Parkins]

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

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

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

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

I guess that question indicates that the part of my message you
did not quote was not written cleanly enough.

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

[Andy Parkins]

On Thursday 2006, December 14 21:30, Junio C Hamano wrote:

> I guess that question indicates that the part of my message you
> did not quote was not written cleanly enough.

It was; I'm just stupid.

Let's make the special case "linux-master" and then Linus gets what he wants 
and consistency is restored.

No?  Okay, I give up then. :-)


Andy

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

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

[Shawn Pearce]

Andy Parkins <andyparkins@gmail.com> wrote:
> On Thursday 2006, December 14 21:30, Junio C Hamano wrote:
> 
> > I guess that question indicates that the part of my message you
> > did not quote was not written cleanly enough.
> 
> It was; I'm just stupid.
> 
> Let's make the special case "linux-master" and then Linus gets what he wants 
> and consistency is restored.
> 
> No?  Okay, I give up then. :-)

What about we do instead:

	[branch]
		mergeMessageTemplate = "Merge '%(remoteref)' from '%(remoteurl)' into '%(localref)'
%(summary)"
	[branch "master"]
		mergeMessageTemplate = "Merge '%(remoteref)' from '%(remoteurl)'
%(summary)"

?  IOW let the user supply the merge template message in the
repository config somehow and use string placeholders like what
show-ref accepts?  Then the default can be to not have the "into" at
all, and Linus surely could just set his branch.mergeMessageTemplate
to a string which gives him the message that he and his fellow
kernel hackers find to be useful?

-- 

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

[Jakub Narebski]

Johannes Schindelin wrote:

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

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

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

[Jakub Narebski]

Shawn Pearce wrote:

> Andy Parkins <andyparkins@gmail.com> wrote:
>> On Thursday 2006, December 14 21:30, Junio C Hamano wrote:
>> 
>> > I guess that question indicates that the part of my message you
>> > did not quote was not written cleanly enough.
>> 
>> It was; I'm just stupid.
>> 
>> Let's make the special case "linux-master" and then Linus gets what he wants 
>> and consistency is restored.
>> 
>> No?  Okay, I give up then. :-)
> 
> What about we do instead:
> 
>       [branch]
>               mergeMessageTemplate = "Merge '%(remoteref)' from '%(remoteurl)' into '%(localref)'
> %(summary)"
>       [branch "master"]
>               mergeMessageTemplate = "Merge '%(remoteref)' from '%(remoteurl)'
> %(summary)"

I disagree about '%(summary)' part, as it is controlled by merge.summary
configuration variable. If you want per branch configuration, why not
branch.<branchname>.mergesummary?

By the way, the above ignores the fact, that besides having hardcoded
that we don't say "into master", we have _two_ merge subject templates:
one for merging from remote, one for merging from local. We might not
have %(remoteurl), then what?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Junio C Hamano]

Jerome Lovy <t2a2e9z8ncbs9qg@brefemail.com> 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.