[PATCH RFC] log: add --from for showing history from a certain rev

[Durham Goode]

On 2/6/15 2:07 PM, Matt Mackall wrote:
> On Fri, 2015-02-06 at 13:17 -0800, Durham Goode wrote:
>> On 2/6/15 12:37 PM, Sean Farley wrote:
>>> Matt Mackall writes:
>>>
>>>> On Fri, 2015-02-06 at 11:26 -0800, Sean Farley wrote:
>>>>> Durham Goode writes:
>>>>>
>>>>>> # HG changeset patch
>>>>>> # User Durham Goode <durham at fb.com>
>>>>>> # Date 1423249495 28800
>>>>>> #      Fri Feb 06 11:04:55 2015 -0800
>>>>>> # Node ID 86c462eee946ce6ce63140fa494e765196107126
>>>>>> # Parent  e1dbe0b215ae137eec53ceb12440536d570a83d2
>>>>>> log: add --from for showing history from a certain rev
>>>>>>
>>>>>> Right now it's very obtuse to show the history of a particular rev (hg log -r
>>>>>> 'reverse(::foo)'). This adds a --from option that allows "hg log --from foo".
>>>>>>
>>>>>> Sending as an RFC since the naming might be controversial and there might be
>>>>>> better ways of integrating it with existing commands (like using this to show
>>>>>> history for bookmarks, hg log --from mybook vs hg log --bookmark mybook).
>>>>> As we found out on IRC, both myself and another person got confused with
>>>>> the naming of '--from': we both thought it meant 'foo::'.
>>>>>
>>>>> I do like the idea of this patch for logging the history of a symbol. In
>>>>> most commands, we have '-b' for branch and '-B' for bookmarks. Since we
>>>>> have this new namespace API, why not use that?
>>>>>
>>>>> hg log --name/-N foo
>>>> Log will probably never get another filtering option. It has too many.
>>> Fair enough.
>>>
>>>> We should probably instead figure out why -fr foo doesn't do what's
>>>> wanted.
>> As it stands, -r implies 'show me exactly these' revisions.  So -f
>> doesn't modify -r at all (nor should it I think).
> I don't understand that. In my mind, there are basically two reasonable
> behaviors for hg log -f -r <spec>:
>
>   ::(<spec>)  # follow the revisions in the spec
>
> or the slightly weird and less useful:
>
>   ::. and (<spec>)  # filter the revset relative to .
>
> A third almost meaningless possibility is:
>
>   ::. or (<spec>)  # show the union of two unrelated things
>
> You seem to be arguing for:
>
>   <spec> # silently ignore -f
>
> ..and then adding a whole new flag to do what -f is more or less
> documented to do.
>
I talked about this with Matt in IRC. While it's a bit odd that -f could 
cause log to produce more output than without (normally flags on log 
filter data, not add it), -fr currently does nothing special (it's just 
-r) and is very discoverable, so I think it's a reasonable idea to make 
that work instead.

If no one opposes, I'll send a patch out later.