From: Daniel Barkalow Date: Thu, 23 Jun 2005 16:45:45 GMT Subject: Re: Patch (apply) vs. Pull Message-ID: In-Reply-To: On Wed, 22 Jun 2005, Linus Torvalds wrote: > On Thu, 23 Jun 2005, Daniel Barkalow wrote: > > > > 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. I think that, if we care much about the hashes of diffs, we should hash the diff that's being applied, not hash a regenerated diff (unless, of course, the diff that's being applied has been modified in hash-relevant ways, in which case it's not going to match anything anyway). GNU diff sometimes generates patches which are really terrible to try to read, because it finds some line of punctuation from a removed block that matches a line in an added block and interleaves unrelated content. It would be nice to not have to worry about confusion if there's a mismatch. Wouldn't the only case where this would be a problem be if we had the committer apply the patch, generate a diff, hash it, and stick the hash in the commit? The no-cache version has the diffs for hashing done by the same person with the same program, and the hash-the-applied-patch version has the hashes done on the same patch. > > > 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 think that the whole-chain case is sufficiently common to make special and extra smooth; developers will be making their history forwards every day, and only cherry-picking on occasion. This is also still in the developer's messy history, and I don't think those commits are really worth much as history or organization (although they're wonderful as checkpointing). The cherry-picking there will generally be content-based rather than commit-based, and will mostly be picking out hunks to form a clean patch sequence to replace the history. -Daniel *This .sig left intentionally blank*