Am 11.05.22 um 01:21 schrieb Junio C Hamano:
> <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.
> 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.
Which might motivate them to contribute a patch to add that feature.
Give them a chance! :)
> 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.
FWIW, I'd already be satisfied by a convincing outline of a way towards
a complete solution to accept the partial feature, just to be sure we
don't paint ourselves into a corner. But I'm bad at both strategy and
saying no, so that's that.
Regarding file modes: We only effectively support the executable bit,
so an additional option --add-virtual-executable-file=<path>:<contents>
would suffice. It would also prevent the false impression that
arbitrary file modes can be used ("I said 0123 and got 0644, bug!").
And it would not even be the longest Git option..
René
