On Wed, Jul 3, 2013 at 7:26 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Jens Lindström <j...@opera.com> writes:
>
>> Not always. The Linux kernel can at least be configured not to allow
>> it. It seems this is enabled by default in at least Debian.
>
> You learn a new thing every day, I guess. I am on Debian, I do not
> think I did any customization in that area, and I can hardlink just
> fine.
To configure it, write "1" (on) or "0" (off) to
/proc/sys/fs/protected_{hard,sym}links. I can't remember (or imagine)
that I enabled it on any of my systems. One of my systems is Debian
Squeeze with a 2.6.32 kernel, and it doesn't have those files, so I
guess it might have been added in some more recent kernel version.
>> This restriction had me a bit confused when I was testing variations
>> here; I expected all "access denied" failures to be because of .keep
>> files, but in fact creating hardlinks to other files (.idx and .pack)
>> failed too, even though they were readable.
>
> Is it possible that you are tripping cross-device link? The reason
> why we have "attempt to hardlink but fall back to copy" is exactly
> because it is fairly common that people try local-cheap clone without
> realizing the source and the destination may be on separate filesystems.
No, I was certainly cloning within a single file system, and I can
confirm that a plain "ln src dest" command fails unless the user can
both read and write the source file. So if the cloning user has
read-only access to the repository, copying will work and linking
won't (depending on the kernel,) in which case it of course is
excellent that git falls back to copying instead of linking.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
