aboutsummaryrefslogtreecommitdiff
path: root/contrib
diff options
context:
space:
mode:
authorShawn O. Pearce <spearce@spearce.org>2007-09-05 23:33:41 -0400
committerJunio C Hamano <gitster@pobox.com>2007-09-05 22:24:54 -0700
commitea09ea22d65d118328642e03ad23c8257304499d (patch)
treeb30f61aac6b354bafb1d0660f7a4217ee577fe5d /contrib
parent6b763c424e4ace1678ade5310f3ca3ffbd11af2c (diff)
downloadgit-ea09ea22d65d118328642e03ad23c8257304499d.tar.gz
git-ea09ea22d65d118328642e03ad23c8257304499d.tar.xz
Don't allow contrib/workdir/git-new-workdir to trash existing dirs
Recently I found that doing a sequence like the following: git-new-workdir a b ... git-new-workdir a b by accident will cause a (and now also b) to have an infinite cycle in its refs directory. This is caused by git-new-workdir trying to create the "refs" symlink over again, only during the second time it is being created within a's refs directory and is now also pointing back at a's refs. This causes confusion in git as suddenly branches are named things like "refs/refs/refs/refs/refs/refs/refs/heads/foo" instead of the more commonly accepted "refs/heads/foo". Plenty of commands start to see ambiguous ref names and others just take ages to compute. git-clone has the same safety check, so git-new-workdir should behave just like it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'contrib')
-rwxr-xr-xcontrib/workdir/git-new-workdir6
1 files changed, 6 insertions, 0 deletions
diff --git a/contrib/workdir/git-new-workdir b/contrib/workdir/git-new-workdir
index c6e154a84..2838546d1 100755
--- a/contrib/workdir/git-new-workdir
+++ b/contrib/workdir/git-new-workdir
@@ -48,6 +48,12 @@ then
"a complete repository."
fi
+# don't recreate a workdir over an existing repository
+if test -e "$new_workdir"
+then
+ die "destination directory '$new_workdir' already exists."
+fi
+
# make sure the the links use full paths
git_dir=$(cd "$git_dir"; pwd)