Re: Specifying N revisions after the initial commit

[Junio C Hamano <gitster@pobox.com>]

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