On Sat, Dec 12, 2015 at 6:30 PM, Edmundo Carmona Antoranz
<[email protected]> wrote:
>>
>> The 'show_progress = 0' seems unnecessary. What if you did something
>> like this instead?
>>
>> if (show_progress > 0 && (incremental ||
>> (output_option & OUTPUT_PORCELAIN)))
>> die("--progress can't be used with...");
>> else if (show_progress < 0)
>> show_progress = isatty(2);
>>
>>> if (0 < abbrev)
>>> /* one more abbrev length is needed for the boundary commit
>>> */
>>> abbrev++;
>
> Because, if the user didn't provide --[no-]progress option, then the
> value in show_progress will move forward being -1 and then in
> assign_blame, there will be progress output if you chose --incremental
> or porcelain. So, if you chose --incremental or porcelain, we better
> set the value to 0 to make sure there will be _no_ progress. Agree?
Hmmmm.... if the code in assign_blame changed to this, it would be
possible to allow the -1 to go through:
if (show_progress > 0)
pi.progress = start_progress_delay(_("Blaming lines"),
sb->num_lines, 50, 1);
But then I think it would be more 'concise' if we had the value set to
0/1 instead of expecting to see a possible value of -1 there (or
anywhere else) after progressing if progress will be shown or not in
the piece of code we are chatting about.
Comments?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
