Re: What's cooking in git.git (Sep 2010, #05; Wed, 15)

[Michael J Gruber <git@drmicha.warpmail.net>]

Bo Yang venit, vidit, dixit 16.09.2010 17:23:
> On Thu, Sep 16, 2010 at 6:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> [Cooking]
>>
>> * by/line-log (2010-09-11) 18 commits
>>  (merged to 'next' on 2010-09-12 at e29a029)
>>  + log -L: do not free parents lists we might need again
>>  (merged to 'next' on 2010-08-26 at a160ff1)
>>  + Document line history browser
>>  + Add tests for line history browser
>>  + Add --full-line-diff option
>>  + Add --graph prefix before line history output
>>  + Add parent rewriting to line history browser
>>  + Make graph_next_line external to other part of git
>>  + Make rewrite_parents public to other part of git
>>  + Hook line history into cmd_log, ensuring a topo-ordered walk
>>  + Print the line log
>>  + map/take range to the parent of commits
>>  + Add range clone functions
>>  + Export three functions from diff.c
>>  + Parse the -L options
>>  + Refactor parse_loc
>>  + Add the basic data structure for line level history
>>  + parse-options: add two helper functions
>>  + parse-options: enhance STOP_AT_NON_OPTION
>>
>> How would one trace history of lines 440,450 in t/t7300-clean.sh starting
>> from the tip of 'pu'?  "git log -p -L 440,450 pu -- t/t7300-clean.sh"
>> would be the most natural but it does not work (it wants "pu" to be a
>> path).  "git log -p -L 440,450 t/t7300-clean.sh pu" doesn't work either.
> 
> Please put the revision before the '-L' options, you can run:
> 
> git log -p origin/pu  -L 440,450 t/t7300-clean.sh
> 
> It will work.
> 
>> The command line parser of this series needs to be rethought (didn't I say
>> that many times?  Perhaps I was ignored).  Might want to kick this out of
>> 'next' and move to the stalled category after 1.7.3.
> 
> Yes, you have mentioned this many times, and I will put some time on this issue.
> 

I really haven't looked at the feature, but from other commands I would
suspect:

- refs go before paths
- options go before refs

Now, if "-L x,y" is an option /specific to a single file argument/ (not
an overall option for all file arguments) it needs to go before the file
it applies to. Is it file specific?

It would still be nice to make the parser more lenient in the sense that
it accepts an "-L x,y" in the usual place and applies it to all file
arguments.

Michael