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

login
register
mail settings
Submitter Durham Goode
Date Feb. 6, 2015, 7:17 p.m.
Message ID <86c462eee946ce6ce631.1423250276@dev2000.prn2.facebook.com>
Download mbox | patch
Permalink /patch/7715/
State Rejected
Headers show

Comments

Durham Goode - Feb. 6, 2015, 7:17 p.m.
# HG changeset patch
# User Durham Goode <durham@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).
Sean Farley - Feb. 6, 2015, 7:26 p.m.
Durham Goode writes:

> # HG changeset patch
> # User Durham Goode <durham@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

Better suggestions are welcomed.
Matt Mackall - Feb. 6, 2015, 8:30 p.m.
On Fri, 2015-02-06 at 11:26 -0800, Sean Farley wrote:
> Durham Goode writes:
> 
> > # HG changeset patch
> > # User Durham Goode <durham@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.

We should probably instead figure out why -fr foo doesn't do what's
wanted.
Sean Farley - Feb. 6, 2015, 8:37 p.m.
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@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.

I guess it's that 'reverse' is needed for '-r ::foo'. I think it's a
hack but that could be fixed by using '-Gfr ::foo'.
Durham Goode - Feb. 6, 2015, 9:17 p.m.
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@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'd be happy with "hg log -r ::foo", but it prints things in the wrong 
order.  We could invent some new syntax for reverse, but that's only 
mildly less obtuse (and equally undiscoverable).  We could create some 
new syntax for 'history from this rev in reverse order' (hg log -r 
'~foo'), but very few revset operators specify order (aside from 
reverse), so that's kind of wonky (and still not discoverable).

Ideally we'd reverse the default order of all revsets so the newest one 
comes first (since you're almost always more interested in the newer 
revs), but I think that's too big of a BC change.
> I guess it's that 'reverse' is needed for '-r ::foo'. I think it's a
> hack but that could be fixed by using '-Gfr ::foo'.
Matt Mackall - Feb. 6, 2015, 10:07 p.m.
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@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.

For comparison, look at how -m/-M interact with revsets:

$ hg log -q -M -r '::.' | wc
  73691   73692 1389014
$ hg log -q -r '::. and not merge()' | wc
  73691   73691 1389005
$ hg log -q -m -r '::.' | wc
   3712    3712   70519
$ hg log -q -r '::. and merge()' | wc
   3712    3712   70514
Durham Goode - Feb. 6, 2015, 11:02 p.m.
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@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.
Augie Fackler - Feb. 10, 2015, 5:42 p.m.
On Fri, Feb 06, 2015 at 03:02:17PM -0800, Durham Goode wrote:
>
> 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@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.

Can you clarify these statements? My parse of this paragraph was that
I should expect to see a patch that makes "-fr" work as you proposed
--from to, but now I see another patch about --from. Can you elaborate
here before I spend time looking at the new --from patch?

>
> If no one opposes, I'll send a patch out later.
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
Augie Fackler - Feb. 10, 2015, 5:45 p.m.
On Feb 10, 2015, at 12:42 PM, Augie Fackler <raf@durin42.com> wrote:

> On Fri, Feb 06, 2015 at 03:02:17PM -0800, Durham Goode wrote:
>> 
>> 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@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.
> 
> Can you clarify these statements? My parse of this paragraph was that
> I should expect to see a patch that makes "-fr" work as you proposed
> --from to, but now I see another patch about --from. Can you elaborate
> here before I spend time looking at the new --from patch?

Er, I suck at mailreaders. I was seeing the old patch and got confused. The -fr approach sounds reasonable to me, but probably should wait to mail until mpm is back from his vacation.

> 
>> 
>> If no one opposes, I'll send a patch out later.
>> _______________________________________________
>> Mercurial-devel mailing list
>> Mercurial-devel@selenic.com
>> http://selenic.com/mailman/listinfo/mercurial-devel
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel

Patch

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -4372,6 +4372,7 @@  def locate(ui, repo, *pats, **opts):
     ('r', 'rev', [], _('show the specified revision or revset'), _('REV')),
     ('', 'removed', None, _('include revisions where files were removed')),
     ('m', 'only-merges', None, _('show only merges (DEPRECATED)')),
+    ('', 'from', '', _('show history from the given revision')),
     ('u', 'user', [], _('revisions committed by user'), _('USER')),
     ('', 'only-branch', [],
      _('show only changesets within the given named branch (DEPRECATED)'),
@@ -4477,6 +4478,12 @@  def log(ui, repo, *pats, **opts):
     Returns 0 on success.
 
     """
+    if opts.get('from'):
+        if opts.get('rev'):
+            raise util.Abort(_('cannot specify both --rev and --from'))
+        fromrevs = repo.revs(opts.get('from'))
+        opts['rev'] = [revset.formatspec('reverse(::%ld)', fromrevs)]
+
     if opts.get('graph'):
         return cmdutil.graphlog(ui, repo, *pats, **opts)