Re: [ANNOUNCE] Git wiki

From: Petr Baudis <pasky@suse.cz>
Date: May 5, 2006, 18:15 UTC
Message-ID: <20060505181540.GB27689@pasky.or.cz>
In-Reply-To: <20060505005659.9092.qmail@science.horizon.com>

Dear diary, on Fri, May 05, 2006 at 02:56:59AM CEST, I got a letter where linux@horizon.com said that...

Show 13 quoted lines

> But, as Linus has pointed out, this is a very partial solution which
> introduces a lot of difficulties elsewhere.  File renaming is a subset of
> the general class of code reorganizations.  Source files will be split,
> merged, and have functions moved back and forth.  You want the patch to
> find the code it applies to even if that code was moved.
> 
> And that can be done by taking a more global view of the patch.
> Identical file names is only a heuristic.  If the hunk on branch A
> can't find a place to apply on the same file in branch B, then
> you have to look a little harder, either at changes from branch B
> that introduce matching code elsewhere, or perhaps looking
> through history for a change that removed the match from the
> obvious place to see if it added a match elsewhere.

There are really two distinctions here which should be kept separate: automatic vs. explicit movement tracking and file-level vs. subfile-level movement tracking.

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

However, I guess the explicit movement tracking completely fails if you go sub-file (without being extremely bothersome for the user) - you would have to have control over the editor and the clipboard and even then I'm not sure if you could reach any sensible results.

I still dislike automated movement tracking for whole files, but I'm conciliated with it. Because it is probably the only really sensible way to implement subfile-level tracking. It would not be hard to implement using pickaxe (actually, I believe it was near the top of Junio's TODO few weeks ago) and a similarity detector comparing new and old version (if it's dissimilar enough, check if that or a similar hunk was not added somewhere else in the same commit; well, at least the idea sounds simple).

One obvious problem are ambiguities - several similar files are renamed to other similar files and now how do you decide which version to choose? Merge the change to all the new files? Only to some? Panic? I wonder how does the current recursive strategy deal with that. Of course, this case sounds quite artificial and rare for whole files, but I suspect that it will be much more common once you do not deal with files but just hunks, moving bits of code around.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.