From: Junio C Hamano <gitster@pobox•com>
To: randall.s.becker@rogers•com
Cc: git@vger•kernel.org, "Randall S. Becker" <rsbecker@nexbridge•com>
Subject: Re: [PATCH v4 1/4] Add tar extract install options override in installation processing.
Date: Wed, 24 Jan 2018 12:33:09 -0800 [thread overview]
Message-ID: <xmqq607rdmka.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20180121234203.13764-2-randall.s.becker@rogers.com> (randall s. becker's message of "Sun, 21 Jan 2018 18:42:00 -0500")
randall.s.becker@rogers•com writes:
> From: "Randall S. Becker" <rsbecker@nexbridge•com>
> Subject: Re: [PATCH v4 1/4] Add tar extract install options override in installation processing.
We typically start the subject with some short token to help readers
of "git shortlog --no-merges" identify what area is being touched,
e.g. something like
Subject: [PATCH 1/4] Makefile: allow customizing tar extract options for installation
> Introduced TAR_EXTRACT_OPTIONS as a configuration option to change
> the options of tar processing during extract. The default value is "o"
> which synthesizes xof, by default.
And then we order the codebase "to be like so" (or, give an order to
a patch monkey "to make the resulting code like so").
i.e. something like:
Introduce TAR_EXTRACT_OPTIONS to allow customizing the tar
options used when installing. The default value is "o", which ...
What is missing from the log message is the most important thing,
though. Everything you wrote (i.e. what build-time knob is being
added, what is tweaked and what the default is) we can read from the
patch text itself, but readers will be left wondering why anybody
would want to change "o" and change it to what else under what
circumstances to achieve what. I am guessing something like this
might be the reason behind this change
This allows an implementations of "tar" that lacks the 'o'
(--no-same-owner) extract option to be used (even though the
resulting installed versions will keep ownership of whoever
happened to have built them, instead of being owned by 'root')
but please do not make readers guess.
Having said all that, I wonder if this "go to po/build/locale, tar
everything up and then extract it elsewhere" is truly necessary.
IOW, why isn't it sufficient to do this instead, for example?
umask 022 && cp -r po/build/locale/. '$(DESTDIR_SQ)$(localedir_SQ)'
>
> Signed-off-by: Randall S. Becker <rsbecker@nexbridge•com>
> ---
> Makefile | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 1a9b23b67..78ee431b7 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -429,6 +429,10 @@ all::
> # running the test scripts (e.g., bash has better support for "set -x"
> # tracing).
> #
> +# Define TAR_EXTRACT_OPTIONS if you want to change the default behaviour
> +# from xvf to something else during installation. The option only includes
> +# "o" as xf are required.
> +#
> # When cross-compiling, define HOST_CPU as the canonical name of the CPU on
> # which the built Git will run (for instance "x86_64").
>
> @@ -452,6 +456,7 @@ LDFLAGS =
> ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
> ALL_LDFLAGS = $(LDFLAGS)
> STRIP ?= strip
> +TAR_EXTRACT_OPTIONS = o
>
> # Create as necessary, replace existing, make ranlib unneeded.
> ARFLAGS = rcs
> @@ -2569,7 +2574,7 @@ install: all
> ifndef NO_GETTEXT
> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(localedir_SQ)'
> (cd po/build/locale && $(TAR) cf - .) | \
> - (cd '$(DESTDIR_SQ)$(localedir_SQ)' && umask 022 && $(TAR) xof -)
> + (cd '$(DESTDIR_SQ)$(localedir_SQ)' && umask 022 && $(TAR) x$(TAR_EXTRACT_OPTIONS)f -)
> endif
> ifndef NO_PERL
> $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
next prev parent reply other threads:[~2018-01-24 20:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-21 23:41 [PATCH v4 0/4] Force pipes to flush immediately on NonStop platform randall.s.becker
2018-01-21 23:42 ` [PATCH v4 1/4] Add tar extract install options override in installation processing randall.s.becker
2018-01-24 20:33 ` Junio C Hamano [this message]
2018-01-24 22:01 ` Todd Zullinger
2018-01-24 22:27 ` Randall S. Becker
2018-01-24 23:39 ` Ramsay Jones
2018-01-21 23:42 ` [PATCH v4 2/4] Define config options required for the HPE NonStop NSX and NSE platforms randall.s.becker
2018-01-24 21:19 ` Junio C Hamano
2018-01-24 21:49 ` randall.s.becker
2018-01-21 23:42 ` [PATCH v4 3/4] Bring NonStop platform definitions up to date in git-compat-util.h randall.s.becker
2018-01-24 20:36 ` Junio C Hamano
2018-01-24 20:49 ` Randall S. Becker
2018-01-24 21:17 ` Junio C Hamano
2018-01-24 21:45 ` Junio C Hamano
2018-01-24 21:51 ` Randall S. Becker
2018-01-21 23:42 ` [PATCH v4 4/4] Add intptr_t and uintptr_t to regcomp.c for NonStop platform randall.s.becker
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=xmqq607rdmka.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=randall.s.becker@rogers$(echo .)com \
--cc=rsbecker@nexbridge$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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