Re: [PATCH 3/3] t3600: test rm of path with changed leading symlinks

From: Jeff King <peff@peff.net>
Date: Apr 5, 2013, 05:04 UTC
Message-ID: <20130405050424.GA30533@sigill.intra.peff.net>
In-Reply-To: <7vsj35efne.fsf@alter.siamese.dyndns.org>

On Thu, Apr 04, 2013 at 09:59:49PM -0700, Junio C Hamano wrote:

Show 13 quoted lines

> > That means the worst case is not the accidental loss of content,
> > but rather confusion by the user when a copy of a file another
> > part of the tree is removed.
> 
> A copy of a file that is on the filesystem that may not be related
> to the project at all may be lost, and the user may not notice the
> lossage for quite a while.  A symlink that points at /etc/passwd may
> cause the file to be removed and the user will hopefully notice, but
> if the pointed-at file is something in $HOME/tmp/ that you occasionally
> use, you may not notice the lossage immediately, and when you notice
> the loss, the only assurance you have is that there is a blob that
> records what was lost _somewhere_ in _some_ of your project that had
> a symlink that points at $HOME/tmp/ at some point in the past.

It's actually quite hard to lose those files. We will only remove the file if it has a matching index entry. So you cannot do:

  ln -s /etc foo
  git rm foo/passwd

because there is no index entry for foo/passwd. You would have to do:

  mkdir foo
  echo content >foo/passwd
  git add foo/passwd
  rm -rf foo
  ln -s /etc foo
  git rm foo/passwd

and then you only lose it if it matches exactly "content". And recovering it, you know that the original path that held the content was called "passwd". So yes, technically you could lose a file outside of the repo and have trouble finding which path it came from later. But in practice, not really.

Anyway, it is academic at this point. :)

-Peff