From: Jeff King <peff@peff.net>
To: Edmundo Carmona Antoranz <eantoranz@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, Git List <git@vger.kernel.org>
Subject: Re: About global --progress option
Date: Thu, 5 Nov 2015 02:08:41 -0500 [thread overview]
Message-ID: <20151105070841.GC4725@sigill.intra.peff.net> (raw)
In-Reply-To: <CAOc6etbuK7=-8kH60taO8uH+6XNGTFRNGmmkswgP-19bCRNB3Q@mail.gmail.com>
On Thu, Nov 05, 2015 at 12:47:22AM -0600, Edmundo Carmona Antoranz wrote:
> On the technical side, I think the global --progress option (and
> removing the option from the builtins) would not add complexity but
> the opposite because setting the flag would be done at the "main git"
> level and then all the builtins would just forget about it and would
> use progress regardless (cause deciding _if_ progress should be shown
> or not won't be up to them anymore) so the code from the builtins to
> support the option would be gone. It would certainly be more complex
> while keeping global and builtin options alive. Anyway, I do
> understand your concerns and will stand down on the topic (as in....
> global --progress who???).
I think you are missing one important element, which is that git
programs do not all share a memory space with the main git binary. So
you cannot simply set the "progress" variable in the main program and
expect everybody to see it. Running "git foo" may invoke a separate
"git-foo" program, written in another language entirely.
For that reason, options to the main git binary typically set an
environment variable which is communicated to all sub-processes. For an
example, see how "--literal-pathspecs" is implemented. So it actually
does add some complexity.
That being said, the environment variable can be a good thing. For
example, imagine I have a script "git-foo" which runs several commands,
including "git-fetch". It's cumbersome for "git-foo" to take a
"--progress" option and then pass that down to "git-fetch". If you could
instead run:
git --no-progress foo
and have that flag magically propagate to any git sub-programs which
care about showing progress, then that could perhaps make the feature
worthwhile (I say perhaps because while it seems plausible to me, I have
not heard of anyone actually wanting this feature in practice).
But adding in "git --progress" is an orthogonal decision to removing
support for "git <cmd> --progress". I do not see any big advantage to
the latter at this point, and a lot of potential negatives as we break
scripts and user expectations.
-Peff
prev parent reply other threads:[~2015-11-05 7:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-05 3:13 About global --progress option Edmundo Carmona Antoranz
2015-11-05 6:11 ` Junio C Hamano
2015-11-05 6:47 ` Edmundo Carmona Antoranz
2015-11-05 7:08 ` Jeff King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151105070841.GC4725@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=eantoranz@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).