# git rev-list ordering 8 messages from 2008-11-16 to 2008-11-19. Participants: Ian Hilt, Sverre Rabbelier, Johannes Schindelin, Pete Harlan, Björn Steinbrink. Thread: https://gitlist.dev/t/16346 ## Ian Hilt, 2008-11-16 00:44 Subject: git rev-list ordering Message-ID: URL: https://gitlist.dev/e/alpine.LFD.2.00.0811151922310.2935%40sys-0.hiltweb.site ``` Why is it that this command, git rev-list --reverse --max-count=1 results in the same SHA1 as, git rev-list --max-count=1 So far, the documentation and the mailing list archives haven't helped. ``` ## Sverre Rabbelier, 2008-11-16 01:27 Subject: Re: git rev-list ordering Message-ID: URL: https://gitlist.dev/e/bd6139dc0811151727k605a3575hf409fed32a3a4baf%40mail.gmail.com In-Reply-To: ``` On Sun, Nov 16, 2008 at 01:44, Ian Hilt wrote: > Why is it that this command, > > git rev-list --reverse --max-count=1 > > results in the same SHA1 as, > > git rev-list --max-count=1 > > So far, the documentation and the mailing list archives haven't helped. 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 -- Cheers, Sverre Rabbelier ``` ## Ian Hilt, 2008-11-16 01:44 Subject: Re: git rev-list ordering Message-ID: URL: https://gitlist.dev/e/alpine.LFD.2.00.0811152040570.2935%40sys-0.hiltweb.site In-Reply-To: ``` 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? ``` ## Johannes Schindelin, 2008-11-16 21:16 Subject: Re: git rev-list ordering Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0811162215370.30769%40pacific.mpi-cbg.de In-Reply-To: ``` 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. Ciao, Dscho ``` ## Ian Hilt, 2008-11-17 01:21 Subject: Re: git rev-list ordering Message-ID: URL: https://gitlist.dev/e/alpine.LFD.2.00.0811162001550.28544%40sys-0.hiltweb.site In-Reply-To: ``` 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. ``` ## Johannes Schindelin, 2008-11-17 01:35 Subject: Re: Re: git rev-list ordering Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0811170231430.30769%40pacific.mpi-cbg.de In-Reply-To: ``` 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 ``` ## Pete Harlan, 2008-11-18 20:28 Subject: Re: git rev-list ordering Message-ID: <4923256B.3000807@pcharlan.com> URL: https://gitlist.dev/e/4923256B.3000807%40pcharlan.com In-Reply-To: ``` 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 have a script that runs periodically where I need to know the email address of who added $file to the system, for a handful of $files, because I'm moving them somewhere else and want to let them know. The most recent commits aren't interesting, it's the first commit that matters. I use: git rev-list --reverse --pretty=format:%ae HEAD -- $file and the second line has the information I need. Perhaps there's a more straightforward way to answer the question "who first put this file here". (One can imagine that may be no "first", because $file merged from different paths, but in mine as in many real-world cases, it (a) won't happen and (b) whatever happens will be fine if it does.) I don't need this to work differently than it does, but perhaps it constitutes an "interesting situation where you need to list the oldest n commits"? Thank you for your numerous contributions, --Pete ``` ## Björn Steinbrink, 2008-11-19 08:26 Subject: Re: git rev-list ordering Message-ID: <20081119082638.GA3538@atjola.homenet> URL: https://gitlist.dev/e/20081119082638.GA3538%40atjola.homenet In-Reply-To: <4923256B.3000807@pcharlan.com> ``` On 2008.11.18 12:28:27 -0800, Pete Harlan wrote: > I have a script that runs periodically where I need to know the email > address of who added $file to the system, for a handful of $files, > because I'm moving them somewhere else and want to let them know. The > most recent commits aren't interesting, it's the first commit that matters. > > I use: > > git rev-list --reverse --pretty=format:%ae HEAD -- $file > > and the second line has the information I need. > > Perhaps there's a more straightforward way to answer the question "who > first put this file here". > > (One can imagine that may be no "first", because $file merged from > different paths, but in mine as in many real-world cases, it (a) won't > happen and (b) whatever happens will be fine if it does.) > > I don't need this to work differently than it does, but perhaps it > constitutes an "interesting situation where you need to list the oldest > n commits"? What you're asking for are commits that added the file, and you can tell git to find them, instead of using the --reverse work-around: git log --diff-filter=A --pretty=format:%ae HEAD -- $file If you're running that with a single file, you might want to add --follow and maybe add R to the diff-filter as well (to get the renaming commits). Björn ```