Re: Merge commit subjects git.git

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jay Soffian <jaysoffian@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]