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

[Jeff King <peff@peff.net>]

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