Josh Boyer [off-list ref] writes:
On Tue, Sep 22, 2015 at 2:40 PM, Konstantin Khomoutov
...
quoted
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).
On Tue, Sep 22, 2015 at 3:55 PM, Junio C Hamano [off-list ref] wrote:
Josh Boyer [off-list ref] writes:
quoted
On Tue, Sep 22, 2015 at 2:40 PM, Konstantin Khomoutov
...
quoted
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
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