Re: Patch (apply) vs. Pull

On Thu, 23 Jun 2005, Daniel Barkalow wrote:
> 
> 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.

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

> > 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html