Re: [RFC/PATCH] Use work tree to determine if it supports symlinks
- From
- Sascha Cunz <sascha-ml@babbelbox.org>
- Date
- Jul 27, 2012, 23:51 UTC
- Message-ID
- <5249760.yb8Rz8UMH4@mephista>
- In-Reply-To
- <7vsjccyfo6.fsf@alter.siamese.dyndns.org>
On Friday, July 27, 2012 03:58:49 PM you wrote:
> Sascha Cunz <Sascha@babbelbox.org> writes:
Show 5 quoted lines
> > Ok, so repository and working directory are simply not meant to be on > > different file systems. Thanks for the clarification. > > I did not mean "and that is a rule we need to enforce and keep > forever".
I did not parse your statement as such - I just realized, that i probably won't find a valid use case for using 2 file systems with different capabilities. Which lead me to conclude that your "is not supported" is a sufficient response.
Though, I think I have a valid use case for using different file systems: For speed reasons one could setup .git to point to a different drive. I wanted to try this ever since I saw, it would be possible - but I never came around actually trying it. However, if this would turn out to be an improvement, I don't think one would mix file systems with different capabilities (i.e. FAT+ext2).
> I was just answering your (implied) question "why does > code comment, behaviour and documentation disagree?", to give a data > point that would be useful when discussing what the ideal behaviour > should be.
I think, that 'git init --separate-git-dir' (without a 'different filesystems' restriction) is some kind of support for creating non-bare repositories where work tree and .git dir are located on different file systems.
Then, in case a user _did_ setup a peculiar layout, an invocation of 'git submodule init' might make a call to 'git clone', which _should_ set core.symlinks to false but doesn't. At that point the user might not remember in detail how peculiar the setup actually is - and at the same time did not request git to do anything special.
I don't know how far-fetched that is, but it's at least possible.