Re: [RFC/PATCH] log: add log.firstparent option

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> On Fri, Jul 24, 2015 at 08:07:49AM -0700, Junio C Hamano wrote:
>
>> Yeah, you actually convinced me reasonably well that it would
>> happen.  I'd never use it myself.  If people want to shoot
>> themselves in the foot, be my guest ;-)
>> 
>> Perhaps we should drop this, and give a shorter synonym to the
>> option?
>
> I'm still on the fence to have the config kick in only for HEAD.

Hmm, I cannot tell offhand if the confusion factor is worth it (I
didn't say "I don't think it is worth it").  I'd imagine that one
common thing to want is to get an overview of what has happened
upstream since the topic one is currently working on forked from it,
i.e. "log --first-parent ..master", for an individual contributor,
and nother is to see what has happened since the last stable point,
i.e. "log --first-parent origin.." or "log --first-parent v1.0..",
for an integrator.  Neither is covered by the "fp when implied HEAD".

When I am playing an individual contributor, I often want to see my
progress with "log -9" or something, only because "log origin.." is
longer to type and I know my topic is not that long as nine commits.
I guess implied first-parent would not hurt that much in that case,
simply because I do not expect too many merges on a topic, but it
feels wrong to default to first-parent traversal there.

So...

> It feels somewhat magical, but at least the config option name makes it
> painfully clear exactly when it would kick in. I dunno. I am happy
> enough for myself to just run "--first-parent" when that is what I want
> to see. Giving it a shorter name would not help much, I think.

I admit I may be minority, but two common things I do everyday are
"log --first-parent v2.5.0-rc0.." and "log --first-parent master..pu";
I could certainly use a short-hand there.

I already have alias for it, so this is not to help me personally,
but "log -FO" to trigger first-parent one-line would make the alias
unnecessary.

> It is not
> the number of characters, but the fact that most people do not _know_
> that --first-parent exists in the first place, or that it would be
> useful in this case.

That is a separate "education" problem.  My suggestion was more
about "I know there is a way already, but it is cumbersome to type".

> I hoped with a config option it might become
> something projects could recommend to their users[1] if the project has a
> matching workflow. But maybe we could also rely on those same projects
> to educate their users.

They could educate their users to use "log -F" just like they could
tell them to say "config log.firstparent true", I would think.  The
risk of the latter is that those who blindly follow the config path
without understanding what is going on will not even realize that
the problem is that they told Git to only follow the first-parent
path, when they do want to see commits on the side branch, let alone
discovering how to countermand it from the command line one shot.

An instruction to use an extra option, on the other hand, makes it
clear that there is a non-default thing going on, which is more
discoverable: "perhaps I can run it without -F?"