Re: How to efficiently find where a patch applies?

From: Nathan W. Panike <nathan.panike@gmail.com>
Date: May 5, 2011, 20:12 UTC
Message-ID: <20110505201204.GA31572@nwp-laptop>
In-Reply-To: <20110505195556.GA1770@sigill.intra.peff.net>

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

Show 11 quoted lines

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

Show 15 quoted lines

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

Show 5 quoted lines

> 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