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

From: Jeff King <peff@peff.net>
Date: Nov 13, 2015, 23:32 UTC
Message-ID: <20151113233239.GC16173@sigill.intra.peff.net>
In-Reply-To: <AMSPR02MB168F9B2126871F4702CBA5483110@AMSPR02MB168.eurprd02.prod.outlook.com>

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

Show 5 quoted lines

> 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