----- Original Message -----
From: Junio C Hamano
Date: 9/21/2012 11:21 AM
Joshua Jensen <jjen...@workspacewhiz.com> 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
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?

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to