René Scharfe <l.s.r@xxxxxx> writes:
>>> Nevertheless, it is still the most elegant way that I can think of to
>>> generate a diagnostic `.zip` file without messing up the very things that
>>> are to be diagnosed: the repository and the worktree.
>>
>> Puzzled. Are you feeding contents of a .zip file from the command
>> line?
>
> Kind of. Command line arguments are built and handed to write_archive()
> in-process. It's done by patch 3 and extended by 5 and 6.
I meant to ask if this is doing
git archive --store-contents-at-path="report.zip:$(cat diag.zip)"
as I misunderstood what 'the diagnostic .zip file' referred to.
That was a reference to the output of the "git archive" command.
> The number of files is relatively low and they aren't huge, right?
As long as it is expected to fit on the command line, that's fine.
But if the question is "it is OK to add a new option with known
limitation", then it should be stated a bit differently.
"We add this option for use cases where we handle only small number
of one-liner files", and it is OK. We may however want to do
something imilar to what we do to the "-m '<message>'" option used
by "git commit" and "git merge", i.e. add the final LF when it is
missing to make it a complete line, to hint the fact that this is
meant to add a small number of single liner files.
>> Another worry was that when <contents> can have
>> arbitrary bytes, with --opt=<path>:<contents> syntax, the input
>> becomes ambiguous (i.e. "which colon is the <path> separator?"),
>> without some way to escape a colon in the payload.
>
> The first colon is the separator here.
Meaning you cannot have a colon in the path, which is not exactly
pleasing limitation. I know you may not be able to do so on Windows
or CIFS mounted on non-Windows, but we do not limit ourselves to
portable filename character set (POSIX.1 3.282), either.
>> This will throw another monkey wrench to Konstantin's plan [*] to
>> make "git archive" output verifiable with the signature on original
>> Git objects, but it is not a new problem ;-)
>>
>>
>> [Reference]
>>
>> * https://lore.kernel.org/git/20220207213449.ljqjhdx4f45a3lx5@meerkat.local/
>
> I don't see the conflict: If an untracked file is added to an archive
> using --add-file, --add-file-with-content, or ZIP or tar then we'd
> *want* the verification against a signed commit or tag to fail, no? A
> different signature would be required for the non-tracked parts.
Yes, which is exactly how this (and existing --add-file) makes
Konstantin's plan much less useful.
Thanks.
