Re: Patch (apply) vs. Pull

[Daniel Barkalow <barkalow@iabervon.org>]

On Wed, 22 Jun 2005, Linus Torvalds wrote:

> I do realize that people use patch ID's inside various companies already, 
> because it's a nice way to track things. But the fact is, especially with 
> the patch going outside the SCM (which is the whole _point_ here, after 
> all), any modifications will make that ID be dubious.

If this were done within the system, the maintainer would merge a commit
from the author, commit, fix up the whitespace, commit, and push out the
result. The developer then sees that the head was merged, and that
whitespace changes were applied on top of that.

The benefit to an ID that doesn't get changed is that the developer (or
the developer's scripts) can tell that the patch is an ancestor of the new
base tree, which is really important information about maintainer
intent: the remnant in this case is a revert of the maintainer's
changes to the patch, not an independant but conflicting patch.

> And if it _isn't_ modified, then the ID is pointless - you might as well 
> use the SHA1 of the patch itself as its ID, ie not use an explicit ID at 
> all.

My thought was actually to use the hash as the ID, and add headers for
"this patch is a descendant of <other-ID>" as it gets tweaked.

But even in the case where the patch is not modified, the developer can't
retrieve the hash of the applied patch, because it may have applied with
fuzz, in which case diffing the parent's tree with the tree wouldn't
generate a byte-for-byte identical patch. So it would be worth having the
commit store the hash of the submitted patch in a header anyway.

> So I think introducing extra ID's in the process only creates the
> possibility for more confusion. Either the patch is unmodified (and the ID
> is not needed in the first place) or the patch is modified (and the ID
> doesn't convey that).

Do you actually modify patches before applying them, rather than applying
them and the fixing the resulting files? I've never managed to modify
content in a patch (aside from dropping hunks) without upsetting patch. If
you apply them and then fix things, the ID (and for that matter, the 
hash) will be safely conveyed from my system to yours and available for
the commit to mention.

> Which of course is ok, but it's _not_ what I'm interested in if we're
> discussing trying to make git itself have some support for "end-developer
> merges" (re-write history) as opposed to "maintainer merges" (merge
> history).

I believe there are separate issues here: 

 1. pure history rewriting: maintainer merges a developer's
    intermediate head; developer generates a new history in which
    everything later is based on the new mainline.
 2. patches: changes are transferred as diffs over SMTP instead of trees
    inside git.
 3. cherry-picking: maintainer applies some set of changes from a
    developer which is not merging a head the developer created.

I think (1) is easily handled as a merge script that goes through a series
of commits and makes a new series out of merging each of them, rather than
merging the last of them only.

I think (2) should be as transparent as possible, and, in cases where
there was no cherry-picking, be equivalent in the system's behavior to the
result of pull and merge (with the possibility for various cleanup 
happening on top of or along with the merge in either method).

The tricky part is (3), which is currently only possible by going outside
of git. But I think that this is something to tackle separately from
(1) and (2) (where (2) does not involve doing (3)).

	-Daniel
*This .sig left intentionally blank*