Alexandr Miloslavskiy <alexandr.miloslavs...@syntevo.com> writes: > Johannes, thanks for working on this problem! > > In the previous discussion, there was a suggestion to change > '--stdin' to '--paths-file', where '--paths-file -' would mean stdin: > https://public-inbox.org/git/066cfd61-9700-e154-042f-fc9cffbd6...@web.de/ > > I believe that was a good suggestion for a few reasons: > 1) Supporting files in addition to stdin sounds reasonable for its cost. > 2) '--paths-file' will support files and stdin with the same "interface", > avoiding the possible need for another interface later. > 3) '--paths-file' sounds more self-documented then '--stdin'. > > Later, we intend to provide patches to extend the same feature to > multiple other commands, at least {add, checkout, commit, rm, stash}, > and I'm merely trying to avoid possible design issues for this > larger-scale change. > > If you don't mind the suggestion but not willing to spend time > implementing it, we'd like to step in and contribute the remaining > work.
Ahh, I completely forgot about the earlier exchange. Thanks for a pointer. While I do like the idea of adding an option to take the pathspec, which you would usually give from the command line, from the standard input, as a standard technique to lift the command line length limit on various platforms, what I do not find right in the posted patch is that it conflates it with something orthogonal. When you already have a set of paths you would want to give to the command, and when these paths may have wildcard letters in them, you would want to tell the command that you do not want wildcards in the pathspec to take effect. That is a valid wish and we already have a standard solution for that (i.e. the "--literal-pathspecs" option). But it is orthogonal to how you feed these paths to the command. I would not say "unrelated", in that there may be correlation between the cases where you would want to feed pathspec from the standard input and the cases where you would want these pathspec taken litearlly, but the choice is still "orthogonal". If we said "when feeding from the standard input, they are taken literally by default, but on the command line, the wildcards are expanded", that is bad enough---I do not think we want to hear any unnecessary "Git UI is inconsistent" noise raised from such a design choice. The posted patch does not even do that. It takes its input as literal pathspec and it is done unconditionally without any way to override it. If we introduce a new --paths-from-file and make it take only paths and never pathspecs (i.e. no wildcard expansion, a directory does not mean everything underneath it), that would be less worrisome wrt the UI inconsistency front (but we may need to commit to teach existing commands that take pathspec from the standard input the new option, too, so that all subcommands that can take some form of paths specification would work the same way with --paths-from-file). Or we can do --stdin (or --pathspec-from-file=-) that takes pathspecs, whose literal-ness is controlled by the '--literal-pathspecs' option. Thanks.
