Re: [ANNOUNCE] Git wiki

From: Linus Torvalds <torvalds@osdl.org>
Date: May 5, 2006, 18:31 UTC
Message-ID: <Pine.LNX.4.64.0605051123420.3622@g5.osdl.org>
In-Reply-To: <20060505181540.GB27689@pasky.or.cz>

On Fri, 5 May 2006, Petr Baudis wrote:

Show 6 quoted lines

> 
> The automatic vs. explicit movement tracking is a lot more
> controversial. Explicit movement tracking is pretty easy to provide for
> file-level movements, it's just that the user says "I _did_ move file
> A to file B" (I never got the Linus' argument that the user has no idea
> - he just _performed_ the move, also explicitly, by calling *mv).

THE USER DID NO SUCH THING.

Moving data around happens with a whole lot more than "mv".

It happens with patches (somebody _else_ may have done an "mv", without using git at all), and it happens with editors (moving data around until most of it exists in another file).

So doing "*mv" is just a special case.

And supporting special cases is _wrong_. If you start depending on data that isn't actually dependable, that's WRONG.

There's another reason why encoding movement information in the commit is totally broken, namely the fact that a lot of the actions DO NOT WALK THE COMMIT CHAIN!

Try doing

	git diff v1.3.0..

and think about what that actually _means_. Think about the fact that it doesn't actually walk the commit chain at all: it diffs the trees between v1.3.0 and the current one. What if the rename happened in a commit in the middle?

The "track contents, not intentions" approach avoids both these things. The end result is _reliable_, not a "random guess".

Adding file movement note to commits is simply WRONG.

Why does this come up every three months or so? I was right the first time. You'd think that as time passes, people would just notice more and more how right I was and am, instead of forgetting and bringing this idiotic idea up over and over and over again.

		Linus