Re: git rev-list ordering

From: Ian Hilt <ian.hilt@gmx.com>
Date: Nov 17, 2008, 01:21 UTC
Message-ID: <alpine.LFD.2.00.0811162001550.28544@sys-0.hiltweb.site>
In-Reply-To: <alpine.DEB.1.00.0811162215370.30769@pacific.mpi-cbg.de>

On Sun, 16 Nov 2008, Johannes Schindelin wrote:

Show 17 quoted lines

> Hi,
> 
> On Sat, 15 Nov 2008, Ian Hilt wrote:
> 
> > On Sat, 15 Nov 2008, Sverre Rabbelier wrote:
> > > The --reverse is applied after the --max-count, so you are seeing the 
> > > reverse of one commit ;). For comparison, have a look at:
> > > 
> > > $ git rev-list --reverse --max-count=2
> > 
> > Ah, I see.  So if you didn't want the sorting to take a long time for 
> > many commits, you would limit the output to n commits, then sort the 
> > output.  Is this the logic behind this design?
> 
> Yes.  It is by design, since the guy who wrote the initial --reverse 
> support cannot think of an interesting situation where you need to list 
> the oldest n commits.

I see. Well, the situation in which I found this to be needed was while trying to figure out how to find the next commit on branch X while on a detached head from that branch without counting how many commits back I was. In other words,

$ git checkout X~4
$ # now I want X~3 without using a number or carets
$ git checkout $(git rev-list --reverse ..X | head -1)
 -- or --
$ git checkout $(git rev-list ..X | tail -1)

So maybe there's a better way to do this. I don't know. If the commits were reversed _then_ limited I wouldn't need to use the pipe to head/tail. Not that that is a problem, it just seemed like it should work with reverse and max-count.