From: Joshua Jensen Date: Fri, 21 Sep 2012 18:29:50 GMT Subject: Re: Quickly searching for a note Message-ID: <505CB21E.4040607@workspacewhiz.com> In-Reply-To: <7vy5k370n7.fsf@alter.siamese.dyndns.org> ----- Original Message ----- From: Junio C Hamano Date: 9/21/2012 11:21 AM > Joshua Jensen 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