Re: Files not deleted when merging after a rename

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux