Re: Re: git log --merges doesn't show commits as expected

Re: Re: git log --merges doesn't show commits as expected

[Dominik Rauch]

Thank you Jeff for your elaboration! The algorithm is now clear to me and I can see why the log has been empty.

However, I don't think the default simplification algorithm is a good default when used in combination with "--merges". "git log --merges file" looks very natural if I want to answer the question "When has file been merged into my master/develop/whatsoever branch?" and it just doesn't work. Is there a simpler way to answer that question? What is the primary use of "--merges" if not combined with "--full-history" or at least "--first-parent"? I would only see merges where file has been a "merge conflict". What do you think about implying "--full-history" when using "--merges"?

Best regards,
Dominik

> > (This is my first post to this mailing list and I couldn't find a FAQ 
> > section - please excuse me, if I haven't followed all the established 
> > posting guidelines yet.)
> 
> This is the right place. Welcome. :)
> 
> > I have the following repository tree:
> > 
> > C
> > |\
> > | B
> > | /
> > A
> > 
> > Commit A: Parents=(). Initial commit. Contains file foo with content "ABC".
> > Commit B: Parents=(A). Represents a commit on some feature branch. Contains file foo with content "XYZ".
> > Commit C: Parents=(A, B). Represents a merge commit of a feature branch back to the main branch. Contains file foo with content "XYZ".
> > 
> > I expected "git log --merges foo" to show C, however, the log is 
> > empty! Specifying "--full-history" results in the correct history, 
> > therefore I assume, I misunderstand Git's default history 
> > simplification algorithm. Unfortunately, the example in the Git docs 
> > at [1] does not contain the very same situation (although it is 
> > probably one of the most common situations...).
> 
> I don't think "--merges" is relevant to the simplification here. By asking for "foo", that turns on history simplification. Since the merge at C took one side directly, that means we can cull the parent link that leads to A (its foo=ABC did not contribute to the final outcome). And then C is TREESAME to its only remaining parent (they both have foo=XYZ), so it can be removed, leaving only commit B to be passed to the next stage.
> 
> And then we apply "--merges", and see that B is not a merge, and so do not show it (but we still traverse it, of course).
> 
> In theory we could apply "--merges" first (by simplifying history to shrink any chains of non-merges to a single point). But I don't think there's any way to do that currently with git.
> 
> -Peff

Re: Re: git log --merges doesn't show commits as expected

[Jeff King]

On Fri, Nov 13, 2015 at 11:10:44PM +0000, Dominik Rauch wrote:

> However, I don't think the default simplification algorithm is a good
> default when used in combination with "--merges". "git log --merges
> file" looks very natural if I want to answer the question "When has
> file been merged into my master/develop/whatsoever branch?" and it
> just doesn't work. Is there a simpler way to answer that question?

I would generally use --first-parent to just walk down the commits that
first-appeared on the master branch. You don't really need --merges
then; you see all direct changes on the branch, and if you have a topic
branch workflow, you'll essentially only see merges anyway.

> What is the primary use of "--merges" if not combined with
> "--full-history" or at least "--first-parent"?

Using "--merges" is orthogonal to --full-history. You might not even be
simplifying history at all (the reason we do simplification in your
example is because of the "foo" pathspec you provide).

I don't use --merges by itself very much (I use --no-merges much more
often).

> What do you think about implying "--full-history" when using "--merges"?

I haven't thought hard about it, but my first instinct is that we should
not. Even if they are _mostly_ used together, they are orthogonal
concepts, and we'd be breaking backwards compatibility.

-Peff