From: "René Scharfe" <l.s.r@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Sep 2020, #05; Fri, 18)
Date: Sun, 20 Sep 2020 09:58:05 +0200 [thread overview]
Message-ID: <eb128388-01b7-5278-aa0b-1f7d2d5222ba@web.de> (raw)
In-Reply-To: <xmqqy2l5iedh.fsf@gitster.c.googlers.com>
Am 20.09.20 um 00:35 schrieb Junio C Hamano:
> René Scharfe <l.s.r@web.de> writes:
>
>> Am 19.09.20 um 03:41 schrieb Junio C Hamano:
>>> * jc/dist-tarball-tweak (2020-09-09) 1 commit
>>> (merged to 'next' on 2020-09-10 at 36cbe7ee9e)
>>> + Makefile: allow extra tweaking of distribution tarball
>>>
>>> Allow maintainers to tweak $(TAR) invocations done while making
>>> distribution tarballs.
>>
>> Just noticed this one. It reminds me of an alternative solution for
>> archives containing both tracked and untracked files gathering dust on
>> my disk because I didn't see much demand. It goes the other way and
>> gives untracked files the same meta data as tracked ones. Interested?
>>
>> archive: read short blobs in archive.c::write_archive_entry()
>> archive: add --add-file
>> Makefile: use git-archive --add-file
>
> Oooh, so is the idea that we do not have to use $(TAR) to append
> untracked ones to "git archive" output, etc.? If we can get rid of
> all $(TAR) invocations from the build procedure, that would be an
> interesting addition.
The remaining ones are used in the targets install and install-man-perl
for copying po files, Perl libraries and manpages; in artifacts-tar for
archiving binaries etc. and in dist-doc for archiving manpages and HTML
files.
git archive can only solve half of the copy use case at most, so $(TAR)
will still be used -- unless it's replaced by cp+chmod or something
else.
Not sure how to support artifacts-tar. Allowing git-archive calls
without commit or tree might be a start. Letting --add-file record the
full relative path of an untracked entry instead of its basename would
help, perhaps counterbalanced with an additional --strip option similar
to the one of patch(1).
dist-doc tars up directories. This would require adding support for
reading directories to --add-file or adding --add-directory.
René
prev parent reply other threads:[~2020-09-20 8:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-19 1:41 What's cooking in git.git (Sep 2020, #05; Fri, 18) Junio C Hamano
2020-09-19 21:13 ` René Scharfe
2020-09-19 21:23 ` [PATCH 1/3] archive: read short blobs in archive.c::write_archive_entry() René Scharfe
2020-09-19 21:23 ` [PATCH 2/3] archive: add --add-file René Scharfe
2020-09-19 21:23 ` [PATCH 3/3] Makefile: use git-archive --add-file René Scharfe
2020-09-19 22:35 ` What's cooking in git.git (Sep 2020, #05; Fri, 18) Junio C Hamano
2020-09-20 7:58 ` René Scharfe [this message]
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=eb128388-01b7-5278-aa0b-1f7d2d5222ba@web.de \
--to=l.s.r@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).