On 3/14/2020 1:10 PM, Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > >> From: Derrick Stolee <dstolee@xxxxxxxxxxxxx> >> >> "git clone" is used by many build systems to download Git code before >> running a build. The output of these systems is usually color-coded to >> separate stdout and stderr output, which highlights anything over stderr >> as an error or warning. Most build systems use "--quiet" when cloning to >> avoid adding progress noise to these outputs, but occasionally users >> create their own scripts that call "git clone" and forget the --quiet >> option. >> >> Just such a user voiced a complaint that "git clone" was showing "error >> messages" in bright red. The messages were progress indicators for >> "Updating files". >> >> To save users from this confusion, let's default to --quiet when stderr >> is not a terminal window. > > This is the kind of behaviour change that makes me (and probably > others who have been with the project long enough) to say "it is > certain that some other users and tools are relying on the current > behaviour and their expectation, when explained, would look just as > sensible, if not more, than 'any output to the standard error stream > is an error', which is the justfication given for this change." > > I would not be surprised if a GUI program is counting the bytes > coming to the progress output to show the equivalent with bits on > the screen, for example. They would say "Git has always given > progress output to the standard error stream. We, as any other > sensible folks, know that they are not errors and won't give a > misleading and alarming messages in red. We could change our > program to pass --progress but why should we be the one who are > forced to do such a change", and I do not have *any* excuse I find > sensible enough to give them. You are absolutely right. Tools should do the right thing, and users creating their own scripts should understand the output of the commands they are calling. And I was coming back to this thread shortly after waking up since I realized why the test fallout was bigger than I anticipated: this change shouldn't enable "--quiet" but instead "--no-progress". The loss of messages like "Cloning from ..." is actually a problematic behavior change. I'll send a v2 using "--no-progress" instead. > I do not mind queuing this (or any similar backward compatibility > breaking changes) and merging it down to 'next', but if we were plan > to have it in a tagged release, I'd prefer to keep it in 'next' for > at least a few releases before doing so, and under three conditions: > major organizations and those who build tools around Git promise me > that they adopt 'next' for their developers and users early, and > that they actively measure and report potential damages before it is > advanced to 'master', and that they won't let their users complain > after it hits a tagged release. I understand that this is low-priority. This idea of adapting "next" early is interesting to me. It is likely difficult to deploy that branch to CI/CD systems, but I have been thinking of ways to automate our integration process in microsoft/git (and Scalar and VFS for Git) so we find the behavior changes and pain points a lot sooner. I'll see what I can do on this front in the coming weeks. > If the world and userbase were like today back when "clone" learned > the --quiet option and showing the progress meter 15 years ago, I > suspect that we may have chosen this way from the beginning, though. I appreciate your perspective here. I will not be upset if this change is rejected due to backward compatibility concerns. It's tricky to update the user experience around these well-established features like "clone". Thanks, -Stolee
