On Thu, Apr 04, 2013 at 09:59:49PM -0700, Junio C Hamano wrote: > > 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 -- 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