Re: How to efficiently find where a patch applies?

[Jeff King <peff@peff.net>]

On Thu, May 05, 2011 at 01:17:41PM -0500, Nathan W. Panike wrote:

> In the past couple weeks, I have had several occasions where a collaborator has
> sent a patch, which does not have information about where the patch forked from
> master.  I wrote the following scripts to try to discover where the patch
> should be applied.  Is there a better way?

What you have is more or less the best way. As you probably realized,
there could be any number of commits that match the preimage of the diff
exactly. So you are not necessarily finding the fork point, but rather
an appropriate place to apply the patch.

I have to wonder, though, whether it is worth the trouble. If you apply
the patch to your tip, especially using "git am -3", then one of two
things will happen:

  1. The patch will apply cleanly. Either because your tip matched the
     preimage exactly, or because it was close enough and git was able
     to apply anyway.

  2. There are conflicts between what you did and what the patch does.
     In this case, though, what you are doing by searching for the fork
     point will recreate the history locally that your collaborator has.
     But when you go to merge their history, you will end up getting the
     exact same conflicts that you would if you applied to your tip now.

So what is the value in applying their patch to the original fork point?
It better represents the history of what happened. But if you care about
that, I wonder if you should just be pulling from them directly via git
(or if that isn't convenient for some reason, passing around bundles).

> To find the place where the patch applies, I then would run something like
> 
> git rev-list --all | \
> while read commit; do \
> 	git ls-tree -r $commit | \
> 	awk "$(perl ~/programs/git-hacks/create_awk.pl < <patch file>)" > /dev/null || \
> 	echo $commit; \
> done

Wow, dynamically generating awk using perl. That's a new one for me. :)

-Peff