----- Original Message -----
From: Junio C Hamano
Date: 9/21/2012 11:21 AM
Joshua Jensen <jjensen@xxxxxxxxxxxxxxxxx> writes:
Background: To tie Perforce changelists to Git commits, I add a note
to a commit with the form "P4@123456". Later, I use the note to sync
down the closest Perforce changelist matching the Git commit.
I search for these notes by getting a list of revisions:
git rev-list --max-count=1000
I iterate those revisions and run git show and grep on each:
git show -s --format=%N%n%s --show-notes=p4notes COMMIT
For short runs, this isn't so bad. For longer runs of commits (I just
walked through approximately 100), it takes a long time. Running 'git
show' is costing me about 7/10 of second, presumably because I am on
Windows.
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. We saw 300 commits deep once on a long-lived branch that
hadn't been merged in yet, but I'd be surprised to see 1,000.
Still, it shows an arbitrary choice. Really, I want to say to Git: Walk
up the history as far as you need to go from HEAD and return to me the
first commit containing the text "P4@".
Any other thoughts?
-Josh
--
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