Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > Since b57fb80a7d (init, clone: support --separate-git-dir for .git file) > git clone supports the --separate-git-dir option to create the git dir > outside the work tree. But when that option is used, the git dir won't be > deleted in case the clone fails like it would be without this option. This > makes clone lose its atomicity as in case of a failure a partly set up git > dir is left behind. A real world example where this leads to problems is > when "git submodule update" fails to clone a submodule and later calls to > "git submodule update" stumble over the partially set up git dir and try > to revive the submodule from there, which then fails with a not very user > friendly error message. > > Fix that by updating the junk_git_dir variable (used to remember if and > what git dir should be removed in case of failure) to the new value given > with the --seperate-git-dir option. Also add a test for this to t5600 (and > while at it fix the former last test to not cd into a directory to test > for its existence but use "test -d" instead). > > Reported-by: Manlio Perillo <manlio.perillo@xxxxxxxxx> > Signed-off-by: Jens Lehmann <Jens.Lehmann@xxxxxx> > --- I hate to see that git_link is not an argument to init_db() but is a file-scope static in init-db.c to be used to communicate between set_git_dir_init() and init_db(), but that would be a separate thing to be cleaned up, I guess. How is the file that points at the real git dir removed with this fix, by the way? Thanks. -- 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