Specifying revisions in the future

Specifying revisions in the future

[jpaugh]

Hello.

Is it possible to specify revisions in the future? The gitrevisions man
page implies otherwise. Alternatively, is there a way to find out the
number of commits between two revs---assuming one is an ancestor of the
other?

I want to do a certain arbitrary operation for each revision between
where I am now and the tip of the branch.

          v1.0-a     master
            \          \
o---o---o---o---o---o---o
            |
           I am here

I've been using the following to do what I want:

ref=master; \
for i in {5..1}; do \
  echo; \
  git log --stat $ref~$i^\!; \
  read -p 'Full diff? '; \
  echo; \
  if [[ $REPLY == 'y' ]]; then \
    git diff $ref~$i^\!; \
  fi; \
done;

which lists the log and diffstat for last 5 commits between master and
where I am (e.g. an older tag/branch) with an optional full diff. I know
implementing revision specifiers to the future is nontrivial. (I
realized that when I considered non-linear histories.) In this case,
I've distilled it to the point that all I need is the number of commits
between two revs. Can this be had without manually inspecting git log?
Or, is there a better way to get detailed diffs like this?

Thanks.
Jonathan Paugh

Re: Specifying revisions in the future

[Jakub Narebski]

jpaugh@gmx.us writes:

> Hello.

> I want to do a certain arbitrary operation for each revision between
> where I am now and the tip of the branch.
> 
>           v1.0-a     master
>             \          \
> o---o---o---o---o---o---o
>             |
>            I am here

That is the problem X.
 
> Is it possible to specify revisions in the future? The gitrevisions man
> page implies otherwise. Alternatively, is there a way to find out the
> number of commits between two revs---assuming one is an ancestor of the
> other?

That is your idea of a solution, Y.

You have XY problem.  You need to do X, and you think you can use Y to
do X, so you ask about how to do Y.

If you want to list all revsions between v1.0-a and master, use

  git rev-list v1.0a..master

or

  git rev-list --ancestry-path v1.0a..master

depending on definition of _between_ (see "History simplification" in
git-log(1) manpage for description of `--ancestry-path` option).

> 
> I've been using the following to do what I want:
> 
> ref=master; \
> for i in {5..1}; do \
>   echo; \
>   git log --stat $ref~$i^\!; \
>   read -p 'Full diff? '; \
>   echo; \
>   if [[ $REPLY == 'y' ]]; then \
>     git diff $ref~$i^\!; \
>   fi; \
> done;
> 
> which lists the log and diffstat for last 5 commits between master and
> where I am (e.g. an older tag/branch) with an optional full diff. I know
> implementing revision specifiers to the future is nontrivial. (I
> realized that when I considered non-linear histories.) In this case,
> I've distilled it to the point that all I need is the number of commits
> between two revs. Can this be had without manually inspecting git log?
> Or, is there a better way to get detailed diffs like this?

-- 
Jakub Narebski

Re: Specifying revisions in the future

[Jakub Narebski]

Jonathan Paugh wrote:

> > You have XY problem.  You need to do X, and you think you can use Y to
> > do X, so you ask about how to do Y.
> > 
> > If you want to list all revsions between v1.0-a and master, use
> > 
> >   git rev-list v1.0a..master
> > 
> > or
> > 
> >   git rev-list --ancestry-path v1.0a..master
> Thanks. This Y' will take me to lot's of exciting destinations---and I
> must confess I haven't messed with the plumbing heretofore.

Of course you can also do

  git log --ancestry-path v1.0a..master 

-- 
Jakub Narebski
Poland

Re: Specifying revisions in the future

[Matthieu Moy]

jpaugh@gmx.us writes:

> Hello.
>
> Is it possible to specify revisions in the future?

You mean, the opposite of <commit>^ or <commit>~n?

AFAIK, there isn't, and there's a good reason for that: <commit>^ is
well-defined, it's the first parent of <commit>, and it won't change
unless one rewrites this commit.

"the successor of <commit>", OTOH, is not well defined, since there can
be several successors, and one can't order them reliably (you can't
really know the set of successors, because they can exist in different
repositories).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Specifying revisions in the future

[Andreas Schwab]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> "the successor of <commit>", OTOH, is not well defined, since there can
> be several successors, and one can't order them reliably (you can't
> really know the set of successors, because they can exist in different
> repositories).

Yet it would be nice to have a concise notation for "the nth successor
of <commit> towards <commit>" (using --first-parent ordering when
ambiguous).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Specifying revisions in the future

[Jakub Narebski]

Andreas Schwab <schwab@linux-m68k.org> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> 
> > "the successor of <commit>", OTOH, is not well defined, since there can
> > be several successors, and one can't order them reliably (you can't
> > really know the set of successors, because they can exist in different
> > repositories).
> 
> Yet it would be nice to have a concise notation for "the nth successor
> of <commit> towards <commit>" (using --first-parent ordering when
> ambiguous).

First, "the nth successor"... from which refs?  Commit objects have
pointers in one direction only, from commit to its ancestors (earlier
commits).

Second, `--first-parent' won't help here.  Take for example the
following situation:

   ---X<---*<---.<---A
            \
             \--.<---B

X+3 is A or B?  Note that pointers point _to_ '*' commit, so there is
not first or second here - no natural ordering like in the case of
commit parents.

-- 
Jakub Narebski

Re: Specifying revisions in the future

[Junio C Hamano]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> "the successor of <commit>", OTOH, is not well defined, since there can
>> be several successors, and one can't order them reliably (you can't
>> really know the set of successors, because they can exist in different
>> repositories).
>
> Yet it would be nice to have a concise notation for "the nth successor
> of <commit> towards <commit>" (using --first-parent ordering when
> ambiguous).

I thought that 47 different people can build on Linux v3.2 and when you
ask the children of v3.2^0, you would not know which ones to show in what
order, let alone "concise notation to pick one at random among them".

Did you mean --first-child?

Re: Specifying revisions in the future

[Andreas Schwab]

Jakub Narebski <jnareb@gmail.com> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>> 
>> > "the successor of <commit>", OTOH, is not well defined, since there can
>> > be several successors, and one can't order them reliably (you can't
>> > really know the set of successors, because they can exist in different
>> > repositories).
>> 
>> Yet it would be nice to have a concise notation for "the nth successor
>> of <commit> towards <commit>" (using --first-parent ordering when
>> ambiguous).
>
> First, "the nth successor"... from which refs?

>From the first given commit towards the other given commit (the latter
defaulting to HEAD).

> Second, `--first-parent' won't help here.  Take for example the
> following situation:
>
>    ---X<---*<---.<---A
>             \
>              \--.<---B
>
> X+3 is A or B?

If "towards A" then it is A, if "towards B", it is B.  In other words,
to get the "nth successor of C1 towards C2" take the leftmost possible
parent when walking from C2 to C1, then walk back n commits along this
path.  This way you should have an unambigous definition.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Specifying revisions in the future

[Jakub Narebski]

On Sun, 5 Feb 2012, Andreas Schwab wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>>> 
>>>> "the successor of <commit>", OTOH, is not well defined, since there can
>>>> be several successors, and one can't order them reliably (you can't
>>>> really know the set of successors, because they can exist in different
>>>> repositories).
>>> 
>>> Yet it would be nice to have a concise notation for "the nth successor
>>> of <commit> towards <commit>" (using --first-parent ordering when
>>> ambiguous).
>>
>> First, "the nth successor"... from which refs?
> 
> From the first given commit towards the other given commit (the latter
> defaulting to HEAD).

That helps some, but not all situations, see below.
 
> > Second, `--first-parent' won't help here.  Take for example the
> > following situation:
> >
> >    ---X<---*<---.<---A
> >             \
> >              \--.<---B
> >
> > X+3 is A or B?
> 
> If "towards A" then it is A, if "towards B", it is B.  In other words,
> to get the "nth successor of C1 towards C2" take the leftmost possible
> parent when walking from C2 to C1, then walk back n commits along this
> path.  This way you should have an unambigous definition.

Nope, still ambiguous:



  ---X<---*<---.<---A<---.<---M<---
           \                 /
            \--.<---B<------/

Is X+3 A or B?  Though '--first-parent + towards N' is I think unambiguous.
-- 
Jakub Narebski
Poland

Re: Specifying revisions in the future

[Andreas Schwab]

Jakub Narebski <jnareb@gmail.com> writes:

> Nope, still ambiguous:
>
>
>
>   ---X<---*<---.<---A<---.<---M<---
>            \                 /
>             \--.<---B<------/
>
> Is X+3 A or B?  Though '--first-parent + towards N' is I think unambiguous.
                                                   M

X+3->M is A, if A is the leftmost ancestor of M.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Specifying revisions in the future

[Philip Oakley]

From: "Jakub Narebski" <jnareb@gmail.com>
To: "Andreas Schwab" <schwab@linux-m68k.org>
Cc: "Matthieu Moy" <Matthieu.Moy@grenoble-inp.fr>; <jpaugh@gmx.us>; 
<git@vger.kernel.org>
Sent: Sunday, February 05, 2012 10:24 PM
> On Sun, 5 Feb 2012, Andreas Schwab wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>>> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>>>>
>>>>> "the successor of <commit>", OTOH, is not well defined, since there 
>>>>> can
>>>>> be several successors, and one can't order them reliably (you can't
>>>>> really know the set of successors, because they can exist in different
>>>>> repositories).
>>>>
>>>> Yet it would be nice to have a concise notation for "the nth successor
>>>> of <commit> towards <commit>" (using --first-parent ordering when
>>>> ambiguous).
>>>
>>> First, "the nth successor"... from which refs?
>>
>> From the first given commit towards the other given commit (the latter
>> defaulting to HEAD).
>
> That helps some, but not all situations, see below.
>
>> > Second, `--first-parent' won't help here.  Take for example the
>> > following situation:
>> >
>> >    ---X<---*<---.<---A
>> >             \
>> >              \--.<---B
>> >
>> > X+3 is A or B?
>>
>> If "towards A" then it is A, if "towards B", it is B.  In other words,
>> to get the "nth successor of C1 towards C2" take the leftmost possible
>> parent when walking from C2 to C1, then walk back n commits along this
>> path.  This way you should have an unambigous definition.
>
> Nope, still ambiguous:
>
>
>
>  ---X<---*<---.<---A<---.<---M<---
>           \                 /
>            \--.<---B<------/
>
> Is X+3 A or B?  Though '--first-parent + towards N' is I think 
> unambiguous.
> -- 
Is there also a rule missing for X+2, viewed from D, in this example

X<---Y<---Z<---
          \          \
A<----B<----C<----D
as to which order the first parent rule should _not_ be applied when D's 
first parent chain doesn't reach X (it reaches A).
Using 'oldest' first for alternate parent testing would make X+2 = B, whilst 
'newest' first would make X+2=Z. I have used the chain order for 
'newest/oldest', rather than commit date.
(I'm sure that there already exists a natural rule in the dag walk order).

Philip 

Re: Specifying revisions in the future

[Andreas Schwab]

"Philip Oakley" <philipoakley@iee.org> writes:

> Is there also a rule missing for X+2, viewed from D, in this example
>
>X<---Y<---Z<---
>          \          \
>A<----B<----C<----D

This is difficult to interpret since it has some extra indent, let's
assume that Z is the second parent of D and Y the second parent of B.

> as to which order the first parent rule should _not_ be applied when D's
> first parent chain doesn't reach X (it reaches A).
> Using 'oldest' first for alternate parent testing would make X+2 = B,
> whilst 'newest' first would make X+2=Z. I have used the chain order for
> newest/oldest', rather than commit date.

The rule should be to follow the leftmost parent as far as possible.
That means that X+2->D is B.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Specifying revisions in the future

[Miles Bader]

Andreas Schwab <schwab@linux-m68k.org> writes:
> The rule should be to follow the leftmost parent as far as possible.
> That means that X+2->D is B.

It might also be reasonable (and safer -- the user may not actually
realize when there's an ambiguating branch-point) to simply have it
abort with an error ("ambiguous future-ref specification") when
there's any doubt...  I suspect most uses would be very simple "+1"
etc., and not crossing branch points.

-miles

-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'

Re: Specifying revisions in the future

[Matthieu Moy]

Andreas Schwab <schwab@linux-m68k.org> writes:

> The rule should be to follow the leftmost parent as far as possible.

But then, if --first-parent doesn't reach the commit you want, there may
be several paths not following --first-parent that reach it. And you'll
have to invent some more rules to order them.

Sure, that's not impossible, but is the complexity really worth it?

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Specifying revisions in the future

[Andreas Schwab]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> The rule should be to follow the leftmost parent as far as possible.
>
> But then, if --first-parent doesn't reach the commit you want, there may
> be several paths not following --first-parent that reach it. And you'll
> have to invent some more rules to order them.

The leftmost parent is not necessarily the first parent, but the
leftmost parent that still reaches the commit.  It's a depth-first
search: if following the first parent doesn't reach the commit any more,
try again with the second parent.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Specifying revisions in the future

[Jonathan Paugh]

On 02/05/2012 11:28 PM, Miles Bader wrote:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>> The rule should be to follow the leftmost parent as far as possible.
>> That means that X+2->D is B.
> 
> It might also be reasonable (and safer -- the user may not actually
> realize when there's an ambiguating branch-point) to simply have it
> abort with an error ("ambiguous future-ref specification") when
> there's any doubt...  I suspect most uses would be very simple "+1"
> etc., and not crossing branch points.
> 
> -miles
> 

Perhaps default to --linear or --no-cross or such. Whenever there's
ambiguity, it will likely be harder for the user to think about than for
git to resolve it in some defined-as-sane way, at least for many users.

At any rate, I got the answer I needed for my use case (sorry for not
cc-ing the list, and thanks Jakub for that:
http://article.gmane.org/gmane.comp.version-control.git/189926/match=specify+revisions+future).

Still, forward-refs would still be really cool.

Jonathan