Re: merge renamed files/directories?

From: Avery Pennarun <apenwarr@gmail.com>
Date: May 6, 2008, 01:38 UTC
Message-ID: <32541b130805051838k367c44bau715774b46f7894cb@mail.gmail.com>
In-Reply-To: <alpine.LFD.1.10.0805051512060.32269@woody.linux-foundation.org>

On 5/5/08, Linus Torvalds <torvalds@linux-foundation.org> wrote:

>  I really don't understand why people expect a directory rename to be
>  handled automatically, when it is (a) not that common and (b) not obvious
>  what the solution is, but MOST OF ALL (c) so damn _easy_ to handle it
>  manually after-the-fact when you notice that something doesn't compile!

I general I agree with your point here, but I still find it surprising how hard the directory-rename problem is made out to be. As far as I can see, the right implementation exactly parallels the single-file rename implementation.

I think the same problem that prevents git from knowing the difference between empty and nonexistent directories (eg. http://kerneltrap.org/mailarchive/git/2007/7/18/251976) is the one that prevents it from handling directory renames: git doesn't acknowledge that it's *already* treating directories as first-class objects.

What if you thought of a directory as simply a list of filenames? (This is more or less what unix does anyway.) Then an *empty* directory is a tree of zero length; a nonexistent (or not tracked) directory is simply not listed in the parent; a directory with untracked files is like a file with patches not yet added to the index(*); and trying to merge a file into a nonexistent directory (when the original patch *didn't* create the directory fresh) would trigger similar logic to the existing rename handling. That is, put the new file with the content that used to be next to it, by looking for a tree with contents (names, not so much sha1's) similar to the one it was expected to be in.

> It really is mental
> masturbation, and has absolutely no relevance for any real-world problem.

I personally don't get very interested in non-real-world problems. Here's the actual case I tried to use a few months ago, but couldn't, because git doesn't track directory renames. (Note that I was quite happily able to do this in svn, as much as you can do anything happily in svn.)

I have a branch called 'mylib' with my library project in its root directory. What I wanted was to maintain my library in the 'mylib' branch, then merge my library into the "libs/mylib" directory of my application, which is in the 'myapp' branch. (Of course, in real life, there's more than one app using mylib in more than one repository, and I'm actually doing 'git pull' of the mylib branch from elsewhere.)

This actually works like magic in git - except when you create a file in the 'mylib' branch, in which case it gets merged to the wrong path every single time. It seems to me like it should be very easy to put it in the right place instead, making one more interesting use case possible.

I realize git-submodule is the way you're supposed to do something like this, but git-submodule doesn't really do what I want (yet) for reasons discussed in other threads.

Have fun,

Avery

(*) Applying the same metaphor in reverse, operations that are valid on directories are also valid for file contents. I can think of immediate uses for a .gitignore-style list that talks about file *contents*. Imagine if I could make a local patch to my Makefile, mark that one patch as "ignored", and never accidentally check it in.