On Tue, Mar 13 2018, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: > >> Related to this, I came across this bug report >> https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3265 which is >> wondering why we're installing N copies of the git binary, presumably >> they're building with NO_INSTALL_HARDLINKS. >> ... >> But is there any reason anyone can think of for why we shouldn't be >> figuring out the relative path and symlinking the two? > > > There is no fundamental reason not to offer such an "install" method > as an option; unless you count a more philosophical aversion to use > symlinks due to (perceived) additional fragility, that is. > > The resulting code may become messier than without, but as long as > it is without the reasonable range for usual price we would pay for > a new "feature", that would be tolerable, I guess.
Cool. I think it makes sense for us to have this. Here's an implementation of it. The 3/3 patch looks a bit scary, but "git show" with --word-diff will show that the change is minimal. This steals a small piece from Daniel's relocatable series, and doesn't in any way conflict with it. None of this will need to be fixed up to make git relocatable since all the symlinks are relative already. Ævar Arnfjörð Bjarmason (3): Makefile: fix broken bindir_relative variable Makefile: add a gitexecdir_relative variable Makefile: optionally symlink libexec/git-core binaries to bin/git Makefile | 52 +++++++++++++++++++++++++++++++++++----------------- 1 file changed, 35 insertions(+), 17 deletions(-) -- 2.15.1.424.g9478a66081
