On Sun, 16 Nov 2008, Johannes Schindelin wrote: > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
