Don't allow contrib/workdir/git-new-workdir to trash existing dirs
authorShawn O. Pearce <spearce@spearce.org>
Thu, 6 Sep 2007 03:33:41 +0000 (23:33 -0400)
committerJunio C Hamano <gitster@pobox.com>
Thu, 6 Sep 2007 05:24:54 +0000 (22:24 -0700)
commitea09ea22d65d118328642e03ad23c8257304499d
treeb30f61aac6b354bafb1d0660f7a4217ee577fe5d
parent6b763c424e4ace1678ade5310f3ca3ffbd11af2c
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>
contrib/workdir/git-new-workdir