git rev-list ordering

git rev-list ordering

[Ian Hilt]

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

[Sverre Rabbelier]

On Sun, Nov 16, 2008 at 01:44, Ian Hilt <ian.hilt@gmx.com> wrote:
> 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

[Ian Hilt]

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?

Re: git rev-list ordering

[Johannes Schindelin]

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

Re: git rev-list ordering

[Ian Hilt]

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.

Re: Re: git rev-list ordering

[Johannes Schindelin]

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

Re: git rev-list ordering

[Pete Harlan]

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

Re: git rev-list ordering

[Björn Steinbrink]

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