Re: Patch (apply) vs. Pull

From: Linus Torvalds <torvalds@osdl.org>
Date: Jun 23, 2005, 06:09 UTC
Message-ID: <Pine.LNX.4.58.0506222258290.11175@ppc970.osdl.org>
In-Reply-To: <Pine.LNX.4.21.0506230025420.30848-100000@iabervon.org>

On Thu, 23 Jun 2005, Daniel Barkalow wrote:

Show 5 quoted lines

> 
> I bet I'm misunderstanding fuzz; what I actually mean is that, if a patch
> applies after moving it, then regenerating it from the result would give
> the a patch with different line numbers; if these affect the hash, the
> author's tools will be sad.

What GNU patch calls "fuzz" is how badly the context can "not match". A "fuzz factor" of one allows the patch to apply even if the "outermost" of the context lines don't match up. See "man patch".

What you talk about is what they (and I) call "offset", and yes, you must ignore the line numbers when considering two patches identical, exactly because other patches may change their offsets.

So "git-apply" does apply patches that are offset from where the patch claims (and the "claimed position" is really nothing more than a "start searching here" parameter), but git-apply does not allow any fuzz.

Show 9 quoted lines

> > In fact, you could probably replace every run of contiguous whitespace
> > with a single space, and then you'd not have to worry about whitespace
> > differences either. That would be very simple to do, and quite workable: I
> > certainly think it sounds more reliable than just hoping that people
> > always pass on a "patch ID" in their emails..
> 
> That's actually quite plausible. The only case it wouldn't handle is when
> you actually discard parts, and I'm not sure at this point what other
> people should see there.

Yes. One small note of warning: different "diff" algorithms may under some (mostly unlikely) circumstances result in different patches for the difference between the same two files. So when comparin SHA1's of diffs this way, you should also hopefully have the same diff generation algorithm.

That's not likely to be a problem in practice, but it migh be something to keep in mind as a _possible_ source of confusion, where a patch isn't recognized only because it was generated differently from the one that we compare against.

In practice, this can happen today with the "-C" and "-M" flags to diff, of course: two patches look different (and get different SHA1 values) just because one was generated with "rename logic" turned on and the other wasn't..

Show 6 quoted lines

> > Yeah. It probably works well in 99% of the cases to just do a simple
> > "export as patch" + "apply on top with old commit message, author and
> > author-date".
> 
> I think that you'll get better results out of "merge with top" + "commit
> with old commit info, but not listing old commit as a parent".

If I understand you correctly, that assumes that you followed the whole chain, though, and that there was no cherry-picking.

I'd like to keep the door open here for cherry-picking or other transformations ("recreate tree _without_ that one commit"), because it would seem to also be a potentially good way to clean up history, not just move it forward, no?

		Linus