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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html