Re: Specifying N revisions after the initial commit

From: Theodore Ts'o <tytso@mit.edu>
Date: Sep 22, 2015, 20:40 UTC
Message-ID: <20150922204000.GC3318@thunk.org>
In-Reply-To: <CA+5PVA6zUXGs2R-MOoj5sBxwUqM7HP=tx-0WZJzPf71MsjH9MA@mail.gmail.com>

On Tue, Sep 22, 2015 at 04:11:23PM -0400, Josh Boyer wrote:

Show 10 quoted lines

> 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