patchRe: [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 <andyparkins@gmail.com>
---
 builtin-fmt-merge-msg.c |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

Hi,

On Thu, 14 Dec 2006, Andy Parkins 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 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

Johannes Schindelin escreveu:

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

Hi,

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

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

Han-Wen Nienhuys escreveu:

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.

Hi,

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

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

Johannes Schindelin wrote:

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.

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

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.

Hi,

Johannes Schindelin wrote:

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

Jerome Lovy <t2a2e9z8ncbs9qg@brefemail.com> writes:

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.

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

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

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

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

Hi,

On Thu, 14 Dec 2006, Andy Parkins wrote:

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

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

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

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

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.

Andy Parkins <andyparkins@gmail.com> writes:

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.

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

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

Andy

Andy Parkins <andyparkins@gmail.com> writes:

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

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

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

Andy Parkins <andyparkins@gmail.com> wrote:

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?

Shawn Pearce wrote:

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?