Re: Not going beyond symbolic links

On Mon, 4 Aug 2008, Junio C Hamano wrote:

While I admit that I have managed a large directory split across
partitions grafted via symlinks in pre-git days myself, ever since you
started "tracking" symbolic links with 8ae0a8c (git and symlinks as
tracked content, 2005-05-05), you have pretty much been committed to
"track" symbolic links.

Yes, but my point is:

 - IF the cost is exorbitant (which was my question that triggered this: 
   it sure as h*ll _would_ have been too high back in the days of the 
   original symlink-matching code) ...

 - ... then there really are valid cases that say that we could just call 
   it a feature.

That's really my whole argument. Saying that "ok, we will assume that 
existing paths that git already knows about are stable" is not really an 
odd feature. It's one we have lived with for years, and it's one that is 
actually pretty dang trivial to work with. Yes, it can cause unexpected 
behaviour, but if you hit it, that unexpected behavior is actually not 
_that_ hard to work around.

This is all I'm arguing for. People claim that there are 'correctness' 
issues. I say that 'performance issues' are important, and we can and we 
_should_ take performance issues very seriously. So seriously that we'll 
make performance a _feature_ if required.

			Linus