Re: Specifying N revisions after the initial commit

[Konstantin Khomoutov]

On Tue, 22 Sep 2015 14:32:19 -0400
Josh Boyer  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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Specifying N revisions after the initial commit

[Junio C Hamano]

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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Specifying N revisions after the initial commit

[Josh Boyer]

On Tue, Sep 22, 2015 at 2:40 PM, Konstantin Khomoutov
 wrote:
> On Tue, 22 Sep 2015 14:32:19 -0400
> Josh Boyer  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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Specifying N revisions after the initial commit

[Junio C Hamano]

Theodore Ts'o  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 ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Specifying N revisions after the initial commit

[Josh Boyer]

On Tue, Sep 22, 2015 at 3:55 PM, Junio C Hamano  wrote:
> Josh Boyer  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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html