views:

171

answers:

2

I come from an SVN background so I'm not sure what the typical git workflow looks like. When you merge in SVN, you provide a commit message describing the merge. This is necessary because SVN's merge-tracking has historically been poor.

I noticed that git's default behavior is to automatically commit the results of the merge if it is successful. This means that the log normally won't show merges, so everything in the history looks like it was developed in one branch. Is this preferable to showing merges as additional commits? I can think of several reasons why and why not, but I'd like some input from other users.

+4  A: 

Unless you supply the --no-merges option to git log, it will normally show merges which are given a brief auto-generated commit description.

This is usually fine as git records the parentage of the commit and the interesting features of a merge are its constituent branches.

Try a git log --graph --online or use a graphical history viewer and you may (should!) be convinced that the way that git records merges is much more important and useful than a long winded merge commit message.

Merges only really need a detailed commit message if there was something 'magical' that was done in the resolve. As this means manual intervention this is easy to add at the this point.

Charles Bailey
When a merge has conflicts, the merge commit is aborted to let you fix them. You then commit, and get another helpful auto-generated message with a list of files which had conflicts. This is the most common case for adding description - it's helpful to know why there were conflicts and how they were resolved. If there weren't conflicts, the simple auto-generated message tends to be good - though some will add a quick list of features merged in (see git.git for an example of this).
Jefromi
Marking this as the answer because you point out that merges only need messages if something special happens (i.e. manual conflict resolution). I'm so used to writing out the range of revisions being merged in SVN that I just assumed merge messages were necessary everywhere.
ThisSuitIsBlackNot
+3  A: 

I think you are mistaking two situations (or I do not understand what you are asking about).

  1. If you merge a side branch which is direct child of the branch you are currently on, it results in so called fast forward situation. Ordinary git wouldn't create a merge commit, but just advance branch tip, but you can prevent it with --no-ff option.

    The default is to avoid such pointless merges because it plays better in truly distributed development.

  2. If the branch you are on and the branch you are merging are truly divergent, i.e there are on each branch commits which are not on other branch, the git would do a merge, and if it can do a merge without conflict, it would automatically create a merge commit. Such merge commit would have automated commit message, subject to merge.log config variable (formerly merge.summary). You can prevent comitting such an automated commit with --no-commit option.

    Of course "git log" would show merge commits, unless you use "git log --no-merges".

I hope that this explanation would help a bit.

Jakub Narębski
Ah, so that's what fast forward means. Good to know that less trivial merges have automatic commit messages. Thanks for clearing that up.
ThisSuitIsBlackNot