As a person looking at the history, I don't care what this particular commit merged. I only care about the two commits before it. They're the ones with content, they're the ones I'll want to 'git show' ... most likely.
Anyway, we don't have to agree on this, but I do suggest that we come up w/ a standard. Otherwise, we'll see a mess. I personally prefer rebase, but if the project decided to do merge, I'll adopt that and apply it. I'm not going to argue much because aside from aesthetics and cleanup of 'git log', I don't feel knowledgeable enough to argue against one or the other. Shai On Mon, Jan 25, 2016 at 10:11 PM Dawid Weiss <[email protected]> wrote: > > commit 51396b8cf63fd7c77d005d10803ae953acfe659f > > Merge: 5319ca6 6df206a > > > > The 'merged' commit, in this case, seems redundant to me as it doesn't > add > > any useful information about them. > > It tells you exactly which two parent commits this merge actually > joins. In terms of patches -- this tells you which two different > "lines" of patches this commit consolidates. This isn't unimportant > information. > > Think of Solr and Lucene, for example -- the merge commit that glues > the two projects together looks exactly like the one above: it > connects two different lines of (thousands) of patches that in the > result form Lucene-Solr. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
