please pull powerpc-merge.git
Linus Torvalds
torvalds at osdl.org
Sun Nov 20 05:24:14 EST 2005
[ Junio, Fredrik, you're cc'd because the "merge-one-file" logic doesn't
clean up empty directories after removing a file in merge ]
On Sat, 19 Nov 2005, Christoph Hellwig wrote:
>
> Btw, in current Linus' tree arch/ppc64/ contains various empty
> directories, anyone care to git rm -r arch/ppc64 (and include/asm-ppc64
> now) ?
Actually, a git tree can never contain an empty subdirectory (well, it
technically _can_, but it really shouldn't - the index only tracks
_files_, and directories in git are created only as needed to contain
those files. An empty directory tree - while technically possible in a
data structure sense - would be a bug in git if git ever created one).
So when you say "in current Linus' tree", I suspect that in my tree it
very much does not, but in _your_ tree the stale directories still exist
because "git pull" just hasn't removed them.
It's a git bug/misfeature: git does not remove directories when the last
file in it has been removed, simply because git doesn't actually really
even _track_ directories at all. It only tracks files that just happen to
be in directories.
[ Side note: this is not strictly true: git _will_ actually remove
directories that become empty when you switch between different branches
with "git checkout". However, even then it will not actually ever remove
a directory that contains any non-tracked files, so if you have old
object files etc, git will never remove that directory even if all the
tracked files got removed. ]
The reason I say "bug/misfeature" and not outright "bug" is the fact that
removing directories is not something that git can really always do.
Exactly because directories are often used for things that aren't tracked.
Should it just remove old object files? Hell no. Stuff git doesn't know
about (even if they have been marked in ".gitignore") it definitely
shouldn't touch.
So in general, after you've merged somebody elses tree, the final pruning
of your own old checked-out directories is really up to you.
But I agree that git should maybe at least _tell_ people about "there's a
directory there that I'm not tracking". And it could perhaps remove the
empty ones outright a bit more aggressively (ie now it effectively does it
only for "git checkout" and for the _trivial_ cases of merges that happen
with "git pull", but it doesn't do it if the merge ended up being of the
more involved case that needed higher-level - but still automatic - help).
Frederik - I don't do perl, but I think for the recursive merge strategy,
it's the "removeFile()" thing. And for the old git-merge-one-file.sh, it's
that "deleted in both or deleted in one and unchanged in the other" case.
In both cases, I think it should do something like
.. remove the file itself ..
#
# remove all directories leading up the path if they
# have become non-empty
#
path=$(dirname $path)
while [ "$path" ] && rmdir "$path"; do
path=$(dirname $path)
done
or similar.
But as mentioned, quite often, this still won't remove the directories,
since it will have various old stale build-files in them.
Linus
More information about the Linuxppc64-dev
mailing list