"Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > From: Johannes Schindelin <johannes.schindelin@xxxxxx> > > To avoid running into command line limitations, some of Git's commands > support the `--stdin` option. > > Let's use exactly this option in the three rev-list/log invocations in > gitk that would otherwise possibly run the danger of trying to invoke a > too-long command line. Makes perfect sense. I do not know the point of saying exactly here, though. > While it is easy to redirect either stdin or stdout in Tcl/Tk scripts, > what we need here is both. We need to capture the output, yet we also > need to pipe in the revs/files arguments via stdin (because stdin does > not have any limit, unlike the command line). To help this, we use the > neat Tcl feature where you can capture stdout and at the same time feed > a fixed string as stdin to the spawned process. Nice, so this is not about "we may have too many args to fit in our memory", but about "we may have too many args for system to spawn the subprocess with". > One non-obvious aspect about this change is that the `--stdin` option > allows to specify revs, the double-dash, and files, but *no* other > options such as `--not`. It sounds like a design mistake, which may want to be fixed, but of course gitk cannot depend on Git it runs with having such a fix, and use of "^" prefix is a good alternative (after all, "--not" was invented to save us writing ^ in front of many revs). Good.
