Re: git rev-list ordering

From: Pete Harlan <pgit@pcharlan.com>
Date: Nov 18, 2008, 20:28 UTC
Message-ID: <4923256B.3000807@pcharlan.com>
In-Reply-To: <alpine.DEB.1.00.0811162215370.30769@pacific.mpi-cbg.de>

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