Re: [PATCH gitk 0/4] gitk support for git log -L

From: Thomas Rast <trast@inf.ethz.ch>
Date: Jul 31, 2013, 13:17 UTC
Message-ID: <87siyu98cq.fsf@linux-k42r.v.cablecom.net>
In-Reply-To: <51F6CB7D.1070806@web.de>

Jens Lehmann <Jens.Lehmann@web.de> writes:

Show 16 quoted lines

> Am 29.07.2013 21:37, schrieb Thomas Rast:
>> Thomas Rast <trast@inf.ethz.ch> writes:
>> 
>>> Thomas Rast <trast@inf.ethz.ch> writes:
>>>
>>>> Now that git log -L has hit master, I figure it's time to discuss the
>>>> corresponding change to gitk.
>>>
>>> Paul, any news on this?  Any chance we can get it into the next release,
>>> since that will also be the first release to ship with 'git log -L'?
>> 
>> Jens pointed out privately that the handling of unstuck -L options is
>> unfortunate, to put it mildly.  I'll send a reroll.
>
> But as soon as that is fixed I'd really like to see this applied, as
> I think gitk is the perfect tool to show history information.

Unfortunately it's turning out to be harder than I hoped. gitk runs the arguments through git-rev-parse, which only knows that -n gets an unstuck argument. Consequently, gitk accepts an unstuck -n but only stuck forms of -S and -G.

Fixing it through git-rev-parse feels wrong; rev-parse is supposed to know about rev-list options, but -S and -G only make sense in diff-generating walks, and -L only makes any sense at all for git-log.

I'm tempted to leave it at the existing patches for now. That does mean that -L can only be used in the stuck form; it's the same for -S and -G already. Then in a later series we can change gitk's argument parsing to properly treat the options directly, passing only the remaining arguments through to rev-parse to use the usual revision/filename distinction logic.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch