Specifying N revisions after the initial commit

Specifying N revisions after the initial commit

[Josh Boyer]

Hi All,

Please CC me as I'm not subscribed.

I was hoping someone could help me with the revision shorthand to get
the commit sha of a commit N commits after the initial commit.  Thus
far I've figured out that to get the initial commit in a repository,
you can use:

git rev-list --max-parents=0 HEAD

but I can't figure out how to get "give me the commit sha1 of the
commit immediately after the initial commit", or for some number N.  I
could always do something like:

git rev-list HEAD | tail -2

to get both, but I was curious if there was a refspec shorthand for
this that could be used.  It seems that git's rev parsing is all built
on going backwards in order (and probably rightfully so).

Thanks in advance.

josh

Re: Specifying N revisions after the initial commit

[Konstantin Khomoutov]

On Tue, 22 Sep 2015 14:32:19 -0400
Josh Boyer <jwboyer@gmail.com> wrote:

> Please CC me as I'm not subscribed.
> 
> I was hoping someone could help me with the revision shorthand to get
> the commit sha of a commit N commits after the initial commit.

What happens if right after the initial commit, there have been five
branches created -- with no common commits except for the initial one?

That's the core limitation of the data model Git uses (and arguably any
other DVCS system): all commits form a directed acyclic graph.
The "directed" in that construct means that child commits contain a
link to their parent commit (or commits) but not vice-versa.

Hence, given any particular commit, you're able to trace all of its
ancestry, but the reverse is not possible.

Re: Specifying N revisions after the initial commit

[Josh Boyer]

On Tue, Sep 22, 2015 at 2:40 PM, Konstantin Khomoutov
<kostix+git@007spb.ru> wrote:
> On Tue, 22 Sep 2015 14:32:19 -0400
> Josh Boyer <jwboyer@gmail.com> wrote:
>
>> Please CC me as I'm not subscribed.
>>
>> I was hoping someone could help me with the revision shorthand to get
>> the commit sha of a commit N commits after the initial commit.
>
> What happens if right after the initial commit, there have been five
> branches created -- with no common commits except for the initial one?
>
> That's the core limitation of the data model Git uses (and arguably any
> other DVCS system): all commits form a directed acyclic graph.
> The "directed" in that construct means that child commits contain a
> link to their parent commit (or commits) but not vice-versa.

Hm.  It has been so long since I've looked at the underlying model and
git has proven to be so flexible on such a variety of things that I
guess I forgot it was constructed through a DAG.  The --reverse
parameter to git-log and git-rev-parse had left me hopeful.

> Hence, given any particular commit, you're able to trace all of its
> ancestry, but the reverse is not possible.

That makes sense.  I suppose I will have to resort to parsing output
of git-rev-list or something.  Thanks for the reminder.

josh

Re: Specifying N revisions after the initial commit

[Junio C Hamano]

Josh Boyer <jwboyer@gmail.com> writes:

> On Tue, Sep 22, 2015 at 2:40 PM, Konstantin Khomoutov
> ...
>> Hence, given any particular commit, you're able to trace all of its
>> ancestry, but the reverse is not possible.
>
> That makes sense.  I suppose I will have to resort to parsing output
> of git-rev-list or something.  Thanks for the reminder.

I think Konstantin explained why it fundamentally does not make
sense to ask "which one is the Nth one after the root".  I am not
sure how running rev-list and count its output would help, unless
you are now solving a different problem (perhaps "find all the ones
that are Nth after some root", which does have an answer).

Re: Specifying N revisions after the initial commit

[Josh Boyer]

On Tue, Sep 22, 2015 at 3:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Josh Boyer <jwboyer@gmail.com> writes:
>
>> On Tue, Sep 22, 2015 at 2:40 PM, Konstantin Khomoutov
>> ...
>>> Hence, given any particular commit, you're able to trace all of its
>>> ancestry, but the reverse is not possible.
>>
>> That makes sense.  I suppose I will have to resort to parsing output
>> of git-rev-list or something.  Thanks for the reminder.
>
> I think Konstantin explained why it fundamentally does not make
> sense to ask "which one is the Nth one after the root".  I am not
> sure how running rev-list and count its output would help, unless
> you are now solving a different problem (perhaps "find all the ones
> that are Nth after some root", which does have an answer).

Oh, context would help, yes.  In the case of the tree I'm parsing, I
know for a fact that the commit history is entirely linear and will
(should) always remain so.  E.g.

A - B - C - D - E - F ... {N}

So yes, finding e.g. the second commit after the root is complicated
for something resembling anything like a typical git repo, but this
isn't like that.  In other words, I can cheat.  Or at least I'm pretty
sure I can cheat :).

josh

Re: Specifying N revisions after the initial commit

[Theodore Ts'o]

On Tue, Sep 22, 2015 at 04:11:23PM -0400, Josh Boyer wrote:
> Oh, context would help, yes.  In the case of the tree I'm parsing, I
> know for a fact that the commit history is entirely linear and will
> (should) always remain so.  E.g.
> 
> A - B - C - D - E - F ... {N}
> 
> So yes, finding e.g. the second commit after the root is complicated
> for something resembling anything like a typical git repo, but this
> isn't like that.  In other words, I can cheat.  Or at least I'm pretty
> sure I can cheat :).

I'd suggest making your script makes sure "git rev-list --merges A..N"
doesn't output any commits, so you know for sure that the commit
history is linear.  That way you'll be certain that you can cheat.  :-)

	   	    	     	    - Ted

Re: Specifying N revisions after the initial commit

[Junio C Hamano]

Theodore Ts'o <tytso@mit.edu> writes:

> On Tue, Sep 22, 2015 at 04:11:23PM -0400, Josh Boyer wrote:
>> Oh, context would help, yes.  In the case of the tree I'm parsing, I
>> know for a fact that the commit history is entirely linear and will
>> (should) always remain so.  E.g.
>> 
>> A - B - C - D - E - F ... {N}
>> 
>> So yes, finding e.g. the second commit after the root is complicated
>> for something resembling anything like a typical git repo, but this
>> isn't like that.  In other words, I can cheat.  Or at least I'm pretty
>> sure I can cheat :).
>
> I'd suggest making your script makes sure "git rev-list --merges A..N"
> doesn't output any commits, so you know for sure that the commit
> history is linear.  That way you'll be certain that you can cheat.  :-)

There are histories with multiple roots without any merges, in which
case you cannot ;-)