Merge commit subjects git.git

Merge commit subjects git.git

[Jay Soffian]

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.

Re: Merge commit subjects git.git

[Thomas Rast]

Jay Soffian wrote:
> 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.

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);
}


-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Merge commit subjects git.git

[Ævar Arnfjörð Bjarmason]

On Sun, Jul 18, 2010 at 15:33, Thomas Rast <trast@student.ethz.ch> 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))

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)

>                strbuf_addch(out, '\n');
>        else
>                strbuf_addf(out, " into %s\n", current_branch);
> }

Re: Merge commit subjects git.git

[Sverre Rabbelier]

Heya,

On Sun, Jul 18, 2010 at 10:33, Thomas Rast <trast@student.ethz.ch> wrote:
>        if (!strcmp("master", current_branch))

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?

-- 
Cheers,

Sverre Rabbelier

Re: Merge commit subjects git.git

[Ævar Arnfjörð Bjarmason]

On Sun, Jul 18, 2010 at 16:56, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Sun, Jul 18, 2010 at 10:33, Thomas Rast <trast@student.ethz.ch> wrote:
>>        if (!strcmp("master", current_branch))
>
> 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?

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.

Re: Merge commit subjects git.git

[Ilari Liusvaara]

On Sun, Jul 18, 2010 at 05:22:01PM +0000, Ævar Arnfjörð Bjarmason wrote:
> On Sun, Jul 18, 2010 at 16:56, Sverre Rabbelier <srabbelier@gmail.com> 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?

There's yet another place as well, but its only related to obsolete pre-1.5
stuff that has very little use anymore.
 
> 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.

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

Re: Merge commit subjects git.git

[Nicolas Sebrecht]

The 18/07/10, Sverre Rabbelier wrote:
> On Sun, Jul 18, 2010 at 10:33, Thomas Rast <trast@student.ethz.ch> wrote:
> >        if (!strcmp("master", current_branch))
> 
> 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?

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

-- 
Nicolas Sebrecht

Re: Merge commit subjects git.git

[Junio C Hamano]

Jay Soffian <jaysoffian@gmail.com> writes:

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

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.

>   Merge branch 'jn/paginate-fix'

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

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

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

> 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

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.

Re: Merge commit subjects git.git

[Jay Soffian]

On Mon, Jul 19, 2010 at 12:31 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

Ah, thank you for the explanation.

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

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.