On Thu, May 05, 2011 at 03:55:56PM -0400, Jeff King wrote: > 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. Yes. I thought there might be some feature of git-apply that would help me, but now I will stop thinking that. > > 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. > 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. > 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). > 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. > Wow, dynamically generating awk using perl. That's a new one for me. :) You might say it is awk-ward. Thanks, Nathan Panike > > -Peff -- 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