<rsbecker@xxxxxxxxxxxxx> writes: >>If we did "--add-virtual-file=<path>:0644:<contents>" instead from day one, it >>certainly adds a few more lines of logic to this patch, and the calling "scalar >>diagnose" may have to pass a few more bytes, but I suspect that such a change >>would help the project in the longer run. > > Would not core.filemode=false somewhat simulate this? The > consumer-client would not care/do anything with the mode > anyway. Or am I missing something? Or I must be missing something. This is part of "git archive" where its output is a tarball (or a zipfile) in which each entry knows its permission bits (or at least, if it is executable). Running "tar xf" or "unzip" on the receiving end of the output of this command should set the executable bit (and other permission bits) correctly I would certainly hope, so it does matter, no? I did say "scalar diagnose" may not care. But a patch to "git archive" will affect other people, and among them there would be people who say "gee, now I can add a handful of files from the command line with their contents, without actually having them in throw-away untracked files, when running 'git archive'. That's handy!", try it out and get disappointed by their inability to create executable files that way. And obviously I care more about "git archive" than "scalar diagnose". I very welcome to enhance the former to support the need for the latter. I do not see a good reason to stop at a half-feature added to the former, even that added half is enough to satisfy the latter, when the other half is not all that hard to add, and it is reasonably expected that users other than "scalar diagnose" would naturally want the other half, too.
