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 the
On Thu, Nov 5, 2015 at 12:11 AM, Junio C Hamano wrote:
> Besides, I am not convinced that you are bringing in a net positive
> value by allowing "git --no-progress clone". You would need to
> think what to do when you get two conflicting options (e.g. should
> "git --no-progress clone --progress"
Edmundo Carmona Antoranz writes:
> Which would be the correct development path?
>
> - Two-step process: First step, implement global --[no-]progress at
> the git level and also support the option from the builtins that
> laready have it. Let it live like that for some releases (so that
> people h
Hi, everybody!
Coming back from my patch about the --[no-]progress option for
checkout (it's already in next, J), I'd like to build into the
idea of the single --[no-]progress option for git as a whole.
So, in order to know what/how things should be developed, let's start
with a tiny survey
4 matches
Mail list logo
