Hi, On Sun, 16 Nov 2008, Ian Hilt wrote: > On Sun, 16 Nov 2008, Johannes Schindelin wrote: > > > 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) This could break down horribly when there was branching going on. However, in case you are certain there is only one child of X~4, I'd suggest doing this: $ git checkout $(git rev-list --parents --all ^HEAD | sed -n "s/ .*$(git rev-parse HEAD).*$//p") IOW I would list all revisions with parents, and filter out all which do not have the current one as parent. Hth, Dscho -- 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
