Dmitry Potapov, Wed, Jan 23, 2008 09:19:42 +0100: > On Tue, Jan 22, 2008 at 08:28:25AM +0100, Alex Riesen wrote: > > > > Were these subdirectories containing exclusively tracked files? > > Or is it Winblows and some process was blocking the deletion? > > The issue is not Windows specific and the problem can be reproduced > with different versions of Git including the latest from Git master. > > In fact, user B does not have to made any changes, it is enough that > merge was not fast-forward. In contrast with fast-forward merge, which > just update the references, the recursive merge requires the working > directory to perform the merge. Because directories are not trucked, > there is no way to tell at the end whether an empty directory was > created by user before or it became empty as result of merge. Right. I extended Cc a bit, to remind of the problem > Probably, the problem can be solved by remembering the list of empty > directories before performing a real merge and then, on success, to > remove all empty directories that are not in that list. Probably. It is all in merge-recursive.c - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html