Junio C Hamano <gitster@xxxxxxxxx> writes: > Sergey Organov <sorganov@xxxxxxxxx> writes: > >> Jeff King <peff@xxxxxxxx> writes: >> ... >> In this case your original test: >> >> git log --no-diff-merges -p --first-parent [--diff-merges=1: implied] master >> >> would fail, as implied --diff-merges=1 then wins. > > IMHO, I think this is an absolutely wrong thing to do. At least to > me (and I suspect it would be to many users), what "--first-parent > implies 'when showing a diff, compare only with the first parent'" > means is that it should do so unless told to do otherwise. > > git log --no-diff-merges -p --first-parent > > explicitly tells the command that the user does not want to see > patches for merge commits. I do not see any reason why > "--first-parent", which merely *implies* a specific diff generation > preference for merges, countermand it. IOW the implication is > conditional. > > It is like saying > > git log --first-parent > > should show patches because it *implies* comparing only with the > first parent, but you can see why it is wrong. It is because that > implication is conditional---it kicks in only when the command is > told to compare with any parent (i.e. "-p"). > > I.e. the implication is "compare only with the first parent if told > to compare, and if not told what to compare with explicitly". I believe my approach is more straightforward and is free from interpretations. To make my point let's get back to the subject (for a moment :-)). To me "--first-parent implies -m" is simple and unambiguous: (git log [*] --first-parent [*]) == (git log [*] --first-parent -m [*]) No further explanations are needed. The consequence is that an option that is supposed to override -m must follow -m, and thus --first-parent, not precede it, period. Yes, we can invent the rule that implied options don't participate in overriding of explicit options, or that explicit option always overrides all the implicit, or some such, but I see absolutely no reason to complicate the model. Thanks, -- Sergey
