Re: merge renamed files/directories?

["Avery Pennarun" <apenwarr@gmail.com>]

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.