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 -- 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
