René Scharfe writes:
>> One practical problem is that users who do this
>>
>> $ git archive HEAD Documentation/ | tar tf -
>>
>> would be expecting (at least) two different things, depending on the
>> situation they are in.
>>
>> So at least you'd need an "--include-untracked" option, I g
Am 04.01.2018 um 19:22 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> I don't know if it's a good idea, but perhaps we don't even need a new
>> option. We could change how pathspecs of untracked files are handled:
>> Instead of aborting we could include them in the archive. (Sounds like
>>
Dear Junio,
Could you tell me your thought about the way for me to go?
Do you agree with his suggestion; "--uid etc is not the right
solution, --include-untracked is better and generic" ? Or,
should I work "--uid etc" further?
Regards,
mpsuzuki
Junio C Hamano wrote:
René Scharfe writes:
I d
René Scharfe writes:
> I don't know if it's a good idea, but perhaps we don't even need a new
> option. We could change how pathspecs of untracked files are handled:
> Instead of aborting we could include them in the archive. (Sounds like
> the simplest possible interface, but may have practica
Am 04.01.2018 um 03:25 schrieb suzuki toshiya:
> Taking a glance on parse-options.h, I could not find the
> existing class collecting the operands as an array (or
> linked list) from multiple "--xxx=yyy" options. Similar
> things might be the collecting the pathnames to pathspec
> structure. Should
Hi,
Hmm, it could be reasonable to assume that --append-file
would serve more cases than --uid --gid options. There
might be many people who don't care multiple UID/GID in
the source tarball, but want to append some files to the
archive generated by git-archive. I would take a look how
to do tha
Dear René ,
By overlooking your response, I was writing a patch to add
uid/gid into zip archive X-D (not finished yet)
https://github.com/mpsuzuki/git/tree/add-zip-uid-gid
However, I found that most unix platforms use infozip's
extension to store uid/gid instead of pkzip's extension...
So this
[replying only to the list because emails to per...@pluto.rain.com
are rejected by my mail server with the following error message:
"Requested action not taken: mailbox unavailable
invalid DNS MX or A/ resource record."]
Am 02.01.2018 um 01:32 schrieb Perry Hutchison:
> Ren?? Scharfe wrot
Am 02.01.2018 um 07:58 schrieb suzuki toshiya:
> Dear René ,
>
> René Scharfe wrote:
>> Am 29.12.2017 um 15:05 schrieb suzuki toshiya:
>>> The ownership of files created by git-archive is always
>>> root:root. Add --owner and --group options which work
>>> like the GNU tar equivalent to allow over
Dear René ,
René Scharfe wrote:
Am 29.12.2017 um 15:05 schrieb suzuki toshiya:
The ownership of files created by git-archive is always
root:root. Add --owner and --group options which work
like the GNU tar equivalent to allow overriding these
defaults.
In which situations do you use the new o
Ren?? Scharfe wrote:
> Am 29.12.2017 um 15:05 schrieb suzuki toshiya:
> > The ownership of files created by git-archive is always
> > root:root. Add --owner and --group options which work
> > like the GNU tar equivalent to allow overriding these
> > defaults.
> ... the receiver would need to be ro
Am 29.12.2017 um 15:05 schrieb suzuki toshiya:
> The ownership of files created by git-archive is always
> root:root. Add --owner and --group options which work
> like the GNU tar equivalent to allow overriding these
> defaults.
In which situations do you use the new options?
(The sender would ne
The ownership of files created by git-archive is always
root:root. Add --owner and --group options which work
like the GNU tar equivalent to allow overriding these
defaults.
Signed-off-by: suzuki toshiya
---
Documentation/git-archive.txt | 13 +++
archive-tar.c | 8 +-
archive
13 matches
Mail list logo
