Why is it that this command,
git rev-list --reverse --max-count=1 <branch>
results in the same SHA1 as,
git rev-list --max-count=1 <branch>
So far, the documentation and the mailing list archives haven't helped.
Re: git rev-list ordering
On Sun, Nov 16, 2008 at 01:44, Ian Hilt <ian.hilt@gmx.com> wrote:
Show 9 quoted lines
> Why is it that this command, > > git rev-list --reverse --max-count=1 <branch> > > results in the same SHA1 as, > > git rev-list --max-count=1 <branch> > > 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
Re: git rev-list ordering
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 SchindelinRe: git rev-list ordering
Hi,
On Sat, 15 Nov 2008, Ian Hilt wrote:
Show 9 quoted lines
> 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
Re: git rev-list ordering
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.
Johannes SchindelinRe: Re: git rev-list ordering
Hi,
On Sun, 16 Nov 2008, Ian Hilt wrote:
Show 28 quoted lines
> 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
Re: git rev-list ordering
Johannes Schindelin wrote:
Show 16 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 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 SteinbrinkRe: git rev-list ordering
On 2008.11.18 12:28:27 -0800, Pete Harlan wrote:
Show 21 quoted lines
> 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