Re: [PATCH] checkout: add --progress option

On Sat, Oct 31, 2015 at 6:45 PM, Eric Sunshine wrote: > Patches in 'next' are pretty much set in stone, and those in 'master' > definitely are, but 'pu' is volatile, so just send the entire patch > revised, tagged v2 (or v3, etc.), rather than sending a patch to fix >

Re: [PATCH] checkout: add --progress option

On Sat, Oct 31, 2015 at 11:37 AM, Junio C Hamano wrote: > I do find what Peff showed us a lot easier to follow. > > if (opts.show_progress < 0) { > if (opts.quiet) > opts.show_progress = 0; > else >

Re: [PATCH] checkout: add --progress option

Edmundo Carmona Antoranz writes: > + /* > +* Final processing of show_progress > +* Any of these 3 conditions will make progress output be skipped: > +* - selected --quiet > +* - selected --no-progress > +* - didn't select

Re: [PATCH] checkout: add --progress option

I just noticed something interesting. On Sat, Oct 31, 2015 at 11:42 AM, Edmundo Carmona Antoranz wrote: > On Sat, Oct 31, 2015 at 11:37 AM, Junio C Hamano wrote: >> I do find what Peff showed us a lot easier to follow. >> >> if (opts.show_progress

Re: [PATCH] checkout: add --progress option

On Sat, Oct 31, 2015 at 12:14:39PM -0600, Edmundo Carmona Antoranz wrote: > On Sat, Oct 31, 2015 at 11:42 AM, Edmundo Carmona Antoranz > wrote: > > On Sat, Oct 31, 2015 at 11:37 AM, Junio C Hamano wrote: > >> I do find what Peff showed us a lot easier to

Re: [PATCH] checkout: add --progress option

On Fri, Oct 30, 2015 at 10:11 PM, Edmundo Carmona Antoranz wrote: > Ok this is like the previous patch (on top of my patch) but does > post_processing right after parse_options and so there's no need for > the function I had introduced before. Hope it can get your

Re: [PATCH] checkout: add --progress option

One line got wrapped around, hope that's not a problem to understand the whole concept. > +/* > + * Any of these conditions will make progress output be skipped: > + * - selected --quiet > + * - selected --no-progress > + * - (didn't select --progress nor --no-progress) and not working on a >

Re: [PATCH] checkout: add --progress option

Ok this is like the previous patch (on top of my patch) but does post_processing right after parse_options and so there's no need for the function I had introduced before. Hope it can get your blessings so I can send-email the _second_ patch for this feature (following the one that has already

Re: [PATCH] checkout: add --progress option

On Fri, Oct 30, 2015 at 1:37 PM, Junio C Hamano wrote: > > Actually, using a single variable is my preference. In this case I > wanted to illustrate that the value parsed by parse_options() does > not have to be the one that is used in the final location deep in > the

Re: [PATCH] checkout: add --progress option

On Fri, Oct 30, 2015 at 2:48 PM, Junio C Hamano wrote: > Eric Sunshine writes: >> On Thu, Oct 29, 2015 at 9:23 PM, Edmundo Carmona Antoranz >> wrote: >>> + opts.verbose_update = !o->quiet && (option_progress > 0 || >>> +

Re: [PATCH] checkout: add --progress option

On Fri, Oct 30, 2015 at 11:48:36AM -0700, Junio C Hamano wrote: > > Does this logic also need to be applied to the other instance where > > isatty() is consulted in merge_working_tree()? > > This makes me wonder if option_progress and o->quiet change once > parse_options() finished doing its

Re: [PATCH] checkout: add --progress option

Jeff King writes: > I sometimes find it confusing when there are two variables with very > similar meanings (option_progress and show_progress here). I wonder if > we could use one variable, like: > > static int show_progress = -1; > ... > OPT_BOOL(0, "progress", _progress,

Re: [PATCH] checkout: add --progress option

Edmundo Carmona Antoranz writes: > Under normal circumstances, and like other git commands, > git checkout will write progress info to stderr if > attached to a terminal. This option allows progress > to be forced even if not using a terminal. Also, > progress can be skipped

Re: [PATCH] checkout: add --progress option

Eric Sunshine writes: > On Thu, Oct 29, 2015 at 9:23 PM, Edmundo Carmona Antoranz > wrote: >> Under normal circumstances, and like other git commands, >> git checkout will write progress info to stderr if >> attached to a terminal. This option

Re: [PATCH] checkout: add --progress option

On Thu, Oct 29, 2015 at 9:23 PM, Edmundo Carmona Antoranz wrote: > Under normal circumstances, and like other git commands, > git checkout will write progress info to stderr if > attached to a terminal. This option allows progress > to be forced even if not using a terminal.

[PATCH] checkout: add --progress option

Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal. This option allows progress to be forced even if not using a terminal. Also, progress can be skipped if using option --no-progress. Signed-off-by: Edmundo Carmona