Re: How to efficiently find where a patch applies?

["Nathan W. Panike" <nathan.panike@gmail.com>]

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