Specifying revisions in the future

> 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?

> 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 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?

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

> 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.

> 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.

> 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
> 

> 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.

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

> 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).

> > 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.