Re: Patch (apply) vs. Pull

From: Linus Torvalds <torvalds@osdl.org>
Date: Jun 22, 2005, 20:22 UTC
Message-ID: <Pine.LNX.4.58.0506221315201.2353@ppc970.osdl.org>
In-Reply-To: <Pine.LNX.4.21.0506221350130.30848-100000@iabervon.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