Hi Junio, On Mon, 7 Feb 2022, Junio C Hamano wrote: > René Scharfe <l.s.r@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. > "--add-blob=<path>:<blob-object-name>" may be another option, useful > when you have done "hash-object -w" already, and can be used to add > single-liner, or an entire novel. This would mess with the repository. Granted, it is unlikely that adding a tiny blob will all of a sudden work around a bug that the user wanted to report, but less big mutations have been known to subtly change a bug's manifested symptoms. So I really do not want to do that, not in `scalar diagnose. > In any case, "--add-file=<file>", which we already have, would be > more appropriate feature to use to record our "version" file, so > there is no need to change our Makefile for it. Same here. It is bad enough that `scalar diagnose` has to create a directory in the current enlistment. Let's not make the situation even worse. The most elegant solution would have been that streaming `--add-file` mode suggested by René, I think, but that's too involved to implement just to benefit `scalar diagnose`. It's not like we can simply stream the contents via `stdin`, as there are more than one "virtual" file we need to add to that `.zip` file. Ciao, Dscho
