]> git.ipfire.org Git - thirdparty/git.git/commit
clone: better handle symlinked files at .git/objects/
authorMatheus Tavares <matheus.bernardino@usp.br>
Wed, 10 Jul 2019 23:58:56 +0000 (20:58 -0300)
committerJunio C Hamano <gitster@pobox.com>
Thu, 11 Jul 2019 20:52:15 +0000 (13:52 -0700)
commit36596fd2dfa473cf1069d23776e62cc156e7b5c6
treec958a29c6945fe3149959511219bf57f46410c2e
parent03156169270509dc2ecba8324497c9088c4272ed
clone: better handle symlinked files at .git/objects/

There is currently an odd behaviour when locally cloning a repository
with symlinks at .git/objects: using --no-hardlinks all symlinks are
dereferenced but without it, Git will try to hardlink the files with the
link() function, which has an OS-specific behaviour on symlinks. On OSX
and NetBSD, it creates a hardlink to the file pointed by the symlink
whilst on GNU/Linux, it creates a hardlink to the symlink itself.

On Manjaro GNU/Linux:
    $ touch a
    $ ln -s a b
    $ link b c
    $ ls -li a b c
    155 [...] a
    156 [...] b -> a
    156 [...] c -> a

But on NetBSD:
    $ ls -li a b c
    2609160 [...] a
    2609164 [...] b -> a
    2609160 [...] c

It's not good to have the result of a local clone to be OS-dependent and
besides that, the current behaviour on GNU/Linux may result in broken
symlinks. So let's standardize this by making the hardlinks always point
to dereferenced paths, instead of the symlinks themselves. Also, add
tests for symlinked files at .git/objects/.

Note: Git won't create symlinks at .git/objects itself, but it's better
to handle this case and be friendly with users who manually create them.

Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Co-authored-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/clone.c
t/t5604-clone-reference.sh