From: Linus Torvalds Date: Thu, 23 Jun 2005 18:43:13 GMT Subject: Re: Patch (apply) vs. Pull Message-ID: In-Reply-To: On Thu, 23 Jun 2005, Daniel Barkalow wrote: > > 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). But this whole algorithm depends on comparing two git commits, so we don't actually _have_ a diff: we must generate it ourselves from the commits we have in the history (ie we'd compare the commit we're "moving forward" with each commit that we're moving it forward past - in order to see whether it's already been applied). Now, we control both of these patch generations, so in that sense it's easy to just make sure we generate both diffs the same way, but I just wanted to point this fact out. > 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? Right, that would mean that we don't control the hash generation at both points, and would make it fundamentally harder. But since the whole point is that we should be able to generate the ID _without_ it actually being stored away anywhere, this hash approach should work fine. > 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. I'm not convinced. I think a _lot_ of people would want to do re-ordering of patches, combining them, and cherry-picking them if they just had a good way to do that. That would then be a good way of cleaning up messy history too. Just prune the old tree once you've moved it forward. Linus