Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> > We could use that option in Git's own Makefile to add the file named >> > "version", which contains $GIT_VERSION. Hmm, but it also contains a >> > terminating newline, which would be a bit tricky (but not impossible) to >> > add. Would it make sense to add one automatically if it's missing (e.g. >> > with strbuf_complete_line)? Not sure. >> >> I do not think it is a good UI to give raw file content from the >> command line, which will be usable only for trivial, even single >> liner files, and forces people to learn two parallel option, one >> for trivial ones and the other for contents with meaningful size. > > 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? I was mostly worried about busting command line argument limit by trying to feed too many bytes, as the ceiling is fairly low on some platforms. 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. For a single-liner, --add-file-with-contents=<path>:<contents> would be an OK way, and my comment was not a strong objection against this new option existing. It was primarily an objection against changing the way to add the 'version' file in our "make dist" procedure to use it anyway. But now I think about it more, I am becoming less happy about it existing in the first place. 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/
