Re: Specifying N revisions after the initial commit

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 22, 2015, 20:42 UTC
Message-ID: <xmqq1tdq2nkd.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20150922204000.GC3318@thunk.org>

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

Show 15 quoted lines

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