How to efficiently find where a patch applies?

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?

create_awk.pl:
----------------------->8------------------------------------------
#! /usr/bin/env perl
print <<HEADER;
BEGIN {
	i = 0
}
HEADER

print "/";

my $numseen=0;
my $nummatches = 0;
while(<STDIN>){
	if(/^index ([0-9a-f]+)\.\..+$/){
		$hash = $1;
	} else {
		next;
	}
	if($hash =~ /^0*$/) {
		next;
	}
	print "|" if($numseen > 0);
	$numseen = 1;
	++$nummatches;
	print "$hash";	
}
print "/{ i += 1; print \$0}\n";

print <<FOOTER;
END {
	if( i == $nummatches) {
		print "FOUND IT";
		exit 1;
	}
	print "i =",i;
	exit 0;
}
FOOTER
----------------------->8------------------------------------------

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

Nathan Panike

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

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).

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

-Peff

On Thu, May 05, 2011 at 03:55:56PM -0400, Jeff King wrote:

Yes. I thought there might be some feature of git-apply that would help me, but now I will stop thinking that.

The patches were emailed as raw diffs, not as format-patch messages, so I thought git-am was not applicable. Also, I was applying the patches to the git repository on behalf of local colleagues when they ran into problems using 'git-apply'. I did not want to deal with merge conflicts---my colleagues can handle the conflicts themselves. So a clean merge was optimal from my perspective.

Oh, I keep forgetting about bundles. Next time, I might ask them to send a bundle rather than a patch or ask them to use format-patch.

You might say it is awk-ward.

Thanks,

Nathan Panike

On Thu, May 05, 2011 at 03:12:05PM -0500, Nathan W. Panike wrote:

Git-am is basically just a wrapper around git-apply that will split an email message into a raw diff and a commit message. If you have raw diffs in an email, it may handle them OK, or it may be simple enough to massage them into the right form.

As far as I know, there isn't a convenient way to get "git apply" to do the same merge magic for a raw diff that "git am -3" does. It should be possible, as the only relevant input is the raw diff; I just don't think anybody has bothered to do it.

Ah, that makes more sense. I have been in a similar "helping people with git" situation myself.

Ouch. :)

-Peff