Am 21.09.2012 22:25, schrieb Joshua Jensen:
> ----- Original Message -----
> From: Junio C Hamano
> Date: 9/21/2012 2:04 PM
>> Joshua Jensen <jjensen@xxxxxxxxxxxxxxxxx> writes:
>>
>>>> Is there any particular reason you do that as two separate steps?
>>>> It would feel more natural, at least to me, to do something along
>>>> the lines of
>>>>
>>>> git log --show-notes=p4notes -1000
>>>>
>>>>
>>> Thanks for the reply.
>>>
>>> I did not make clear above that I want to stop looking when I find the
>>> first commit that has the note.
>>>
>>> In the case of 'git log --show-notes=p4notes -1000', Git will process
>>> and hand me the log output for 1,000 commits. It is rare I need to
>>> walk that deep.
>> I simply matched it with your initial "rev-list --max-count=1000".
>> The "log" command pages and you can hit 'q' once you saw enough (in
>> other words, you do not have to say -1000).
>>
> This is run via script without user intervention. Presumably, Git will
> do 1,000 commits of work when it may only need to do 1 or 5 or 10?
The trick is to pipe 'git log' output into another process that reads no
more than it needs and exits. Then 'git log' dies from SIGPIPE before it
processed all 1000 commits because its down-stream has gone away.
For example:
git log --show-notes=p4notes -1000 |
sed -n -e '/^commit /h' -e '/P4@/{H;g;p;q}'
(The pipeline keeps track of the most recent 'commit' line, and when it
finds the 'P4@' it prints the most recent 'commit' line followed by the
'P4@' line.)
-- Hannes
--
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