git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "Jeff King" <peff@peff.net>,
	"Andreas Färber" <andreas.faerber@web.de>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH 6/6] Makefile: add a INSTALL_FALLBACK_LN_CP mode
Date: Wed, 31 Mar 2021 21:01:33 +0200	[thread overview]
Message-ID: <87h7krkv02.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <xmqqr1jv6u2u.fsf@gitster.g>


On Wed, Mar 31 2021, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>>> So I would understand if there are two orthogonal knobs
>>>
>>>  - the order of preference (e.g. hardlink > symlink > copy)
>>>  - which ones are allowed (e.g. "no symlinks please")
>>>
>>> but I cannot quite imagine how a system without any fallback would
>>> be useful.
>>
>> Because with explicit knobs I'd like to tell it what to do and not have
>> it auto-guess.
>
> So how would I explicitly tell "I want hardlinks for everything
> else, but use cp when going between /usr/bin and /usr/libexec"
> (because /usr/bin and /usr/libexec is not on the same filesystem
> on this particular box---I'll tell you to use hardlink everywhere
> on another box of mine where they reside on the same filesystem)?

Just as you would now:

    make NO_CROSS_DIRECTORY_HARDLINKS=Y install

That'll get you hardlinks within bin/ and libexec, but copies between
them, and no symlinks.

The behavior change in this series is if your "ln" errors out we'll no
longer silently plow ahead and e.g. not hardlink *within* bin and
libexec in that case.

> Your argument or analogy with openssl does not make much sense to me
> in this case.

The point is the Makefile shouldn't be second-guessing explicit
requests. That's what defaults are for.

  reply	other threads:[~2021-03-31 19:02 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-07 13:20 [PATCH] Makefile: generate 'git' as 'cc [...] -o git+ && mv git+ git' Ævar Arnfjörð Bjarmason
2021-03-07 20:41 ` Junio C Hamano
2021-03-08 12:38   ` Ævar Arnfjörð Bjarmason
2021-03-08 17:21     ` Junio C Hamano
2021-03-08 18:26     ` Jeff King
2021-03-29 16:20 ` [PATCH v2 0/5] Makefile: don't die on AIX with open ./git Ævar Arnfjörð Bjarmason
2021-03-29 16:20   ` [PATCH v2 1/5] Makefile: rename objects in-place, don't clobber Ævar Arnfjörð Bjarmason
2021-03-29 18:21     ` Junio C Hamano
2021-03-29 18:26       ` Junio C Hamano
2021-03-29 23:24       ` Ævar Arnfjörð Bjarmason
2021-03-30  0:21         ` Junio C Hamano
2021-03-31 14:17           ` Ævar Arnfjörð Bjarmason
2021-03-31 18:50             ` Junio C Hamano
2021-03-29 16:20   ` [PATCH v2 2/5] Makefile: rename scripts " Ævar Arnfjörð Bjarmason
2021-03-29 18:40     ` Junio C Hamano
2021-03-29 23:28       ` Ævar Arnfjörð Bjarmason
2021-03-29 16:20   ` [PATCH v2 3/5] Makefile: don't needlessly "rm $@ $@+" before "mv $@+ $@" Ævar Arnfjörð Bjarmason
2021-03-29 18:46     ` Junio C Hamano
2021-03-29 16:20   ` [PATCH v2 4/5] Makefile: add the ".DELETE_ON_ERROR" flag Ævar Arnfjörð Bjarmason
2021-03-29 18:51     ` Junio C Hamano
2021-03-29 23:31       ` Ævar Arnfjörð Bjarmason
2021-03-29 23:58         ` Junio C Hamano
2021-03-30 15:11         ` Jeff King
2021-03-30 18:36           ` Junio C Hamano
2021-03-31  6:58             ` Jeff King
2021-03-31 18:36               ` Junio C Hamano
2021-03-31 22:29                 ` Johannes Schindelin
2021-03-29 16:20   ` [PATCH v2 5/5] Makefile: don't "rm configure" before generating it Ævar Arnfjörð Bjarmason
2021-03-29 16:31   ` [PATCH 0/6] Makefile: make non-symlink & non-hardlink install sane Ævar Arnfjörð Bjarmason
2021-03-29 16:31     ` [PATCH 1/6] Makefile: symlink the same way under "symlinks" and "no hardlinks" Ævar Arnfjörð Bjarmason
2021-03-29 22:17       ` Junio C Hamano
2021-03-29 16:31     ` [PATCH 2/6] Makefile: begin refactoring out "ln || ln -s || cp" pattern Ævar Arnfjörð Bjarmason
2021-03-29 22:20       ` Junio C Hamano
2021-03-29 16:31     ` [PATCH 3/6] Makefile: refactor " Ævar Arnfjörð Bjarmason
2021-03-29 22:24       ` Junio C Hamano
2021-03-30 15:20         ` Jeff King
2021-03-30 18:36           ` Junio C Hamano
2021-03-29 16:31     ` [PATCH 4/6] Makefile: make INSTALL_SYMLINKS affect the build directory Ævar Arnfjörð Bjarmason
2021-03-29 22:31       ` Junio C Hamano
2021-03-31 14:04         ` Ævar Arnfjörð Bjarmason
2021-03-29 16:31     ` [PATCH 5/6] Makefile: use "ln -f" instead of "rm && ln" Ævar Arnfjörð Bjarmason
2021-03-29 22:46       ` Junio C Hamano
2021-03-29 16:31     ` [PATCH 6/6] Makefile: add a INSTALL_FALLBACK_LN_CP mode Ævar Arnfjörð Bjarmason
2021-03-29 22:53       ` Junio C Hamano
2021-03-31 14:03         ` Ævar Arnfjörð Bjarmason
2021-03-31 18:45           ` Junio C Hamano
2021-03-31 19:01             ` Ævar Arnfjörð Bjarmason [this message]
2021-03-29 23:08     ` [PATCH 0/6] Makefile: make non-symlink & non-hardlink install sane Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h7krkv02.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=andreas.faerber@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).