Re: Patch (apply) vs. Pull

[Linus Torvalds <torvalds@osdl.org>]

On Wed, 22 Jun 2005, Daniel Barkalow wrote:
>
> If each patch is given an ID by the author (not committer) which is
> preserved across various later modifications, we could at least recognize
> which patch it was.

I really don't like it.

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.

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.

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). Not to mention the fact that the ID then becomes 
just another thing that can get corrupted or lost or just plain mistakenly 
edited from another patch..

So while I do accept ID's in my workflow (the XFS guys use them to track
commits between their own internal system and the kernel releases), I
really don't like it as a primary mechanism. I think it's useful for
specific projects, but any such usefulness is exactly the fact that then
the tracking of the ID's is totally outside of git itself or any of the
processes of git users.

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

		Linus