Merge commit subjects git.git

Color me curious, but why do the merge commit message in git.git sometimes look like this:

  Merge branch 'jn/paginate-fix'

And other times like this:

  Merge remote branch 'ko/master' into jc/read-tree-cache-tree-fix

I don't really see any rhyme or reason about when the "into ..." is there and when it's not.

Also, the "Sync with 1.7.1.1" merges are I guess are from something like:

  git merge -s ours -m "Sync with 1.7.1.1" maint

?

j.

Jay Soffian wrote:

A merge that does not have the 'into <branch>' bit is a merge to master:

static void do_fmt_merge_msg_title(struct strbuf *out,
	const char *current_branch) {
[...]
	if (!strcmp("master", current_branch))
		strbuf_addch(out, '\n');
	else
		strbuf_addf(out, " into %s\n", current_branch);
}

On Sun, Jul 18, 2010 at 15:33, Thomas Rast <trast@student.ethz.ch> wrote:

Is there anything in Git that records what the canonical branch is? E.g. perl uses "blead", and gets these "into blead" merge commits every time it merges into the main branch.

The HEAD can move, so that can't be checked.

(not that this is an actual problem)

Heya,

On Sun, Jul 18, 2010 at 10:33, Thomas Rast <trast@student.ethz.ch> wrote:

Wow, I thought the only place where we gave "master" any special meaning was in that we create it as the default branch. Can't we fix this to be less hard-coded?

On Sun, Jul 18, 2010 at 16:56, Sverre Rabbelier <srabbelier@gmail.com> wrote:

In addition, Ilari on IRC pointed this out:

    < avar> What does git use to determine what branch gets checked out
            (not always master) on git clone URL?
    < Ilari> avar: HEAD
    < avar> Ah, just the HEAD of the remote, but that doesn't help after
            you've switched branches locally to find out what the main
            is..
    < Ilari> avar: Except that if you have another branch with same commit
             as the one you set to default, either of them may be selected
             (if one is 'master', then the tie is broken for it).

I.e. master is also treated more magically than others when cloning. But I couldn't find the code that does this, so perhaps it doesn't do that.

On Sun, Jul 18, 2010 at 05:22:01PM +0000, Ævar Arnfjörð Bjarmason wrote:

There's yet another place as well, but its only related to obsolete pre-1.5
stuff that has very little use anymore.
 

Its guess_remote_head of remote.c (checked v1.7.2-rc3+). Additionally, it appears that if master doesn't tie for exact match, then first ref in lexical order is choosen (if master ties for exact match, then it is chosen).

Additionally, it appears that if exact HEAD symref information is available (not all protocols support that), then that is choosen with no guessing.

-Ilari

The 18/07/10, Sverre Rabbelier wrote:

To talk about pros and cons I wonder what would be the benefits of changing this. I guess most projects probably best keeping the history consistent for all the merge commit messages.

I think this is more sensible than giving the same behaviour /across/ different repositories (for only which not following the "master" convention).

Jay Soffian <jaysoffian@gmail.com> writes:

The merge messages that are autogenerated by "git merge" (rather, "git fmt-merge-msg") are optimized for Linus's workflow ;-) and hasn't changed much during the past 4-5 years.

You have _one_ primary integration branch (well, by definition, there should be only one "primary") called "master", and when you merge into that branch you are merging work done by a side branch that has been cooking. You get a terse "Merge branch x", "Merge $URL", etc. without "into".

You are not supposed to merge the integration branch into topics without a very good reason. Again, because by default the tool assumes you have one primary integration branch, merging into a branch that is not "master" gets "into ..." so that it will later stand out in the output of "git log" and "git shortlog".

I sometimes/often add some comments explaining why I needed the merge to such a merge with "commit --amend" (the particular one you noticed, jc/read-tree-cache-tree-fix, doesn't have it but I should have. The topic was about fixing an ancient bug and I wanted an early conflict resolution before bringing the fix to more up-to-date codebase).

I almost never use "-s ours"; the only exception is when fixing mistakes, and "merging all the fixes that accumulated on 'maint' to 'master'" is certainly not an example of "fixing mistakes".

This "Sync with 1.7.1.1" is an example of me using "commit --amend" to note the exact reason why this merge of 'maint' to 'master' was made---"to make sure that we have all the fix in the last maintenance release in the development version". Because the fixes to 1.7.1.1 were all cooked first in "master" and then merged to "maint", the result of this particular merge didn't change the tree of "master", but that is not always the case.

On Mon, Jul 19, 2010 at 12:31 PM, Junio C Hamano <gitster@pobox.com> wrote:

Ah, thank you for the explanation.

Can you explain a bit about how you manage the DEF_VER variable in GIT-VERSION-GEN?

I think I was confused not to see GIT-VERSION-GEN listed as a conflict in the merge message, but looking more carefully I see that the files with embedded versions did indeed conflict. Do you just edit this out of the merge message?

j.