Jeff King <peff@xxxxxxxx> writes: > I think this is OK for now, though it does make me wonder if > "--progress" ought to perhaps override "delayed" in some instances, > since it's a positive signal from the caller that they're interested in > seeing progress. I did have the same reaction after seeing the change to 5318 where the expected output from "git commit-graph write --progress" has become unreliable. I think there are possibly three kinds of folks: - I do not want the output smudged with any progress (e.g. I am a script); - I want to see progress if it takes very long, but do not waste vertical screen real estate if it does not make me wait (e.g. I am an interactive user who occasionally wants a cue to leave the keyboard to grab coffee); and - I want to see all progress (... now who am I? Taking a screenshot to write a tutorial or something???). In the ideal world, the three choices above should probably be "--progress=(no|auto|always)" where not having any defaults to one of them (probably "auto", as the code can use isatty() to further turn it to "no"). Making "--progress" to mean "--progress=always" is OK, but it leaves no way to override an earlier --[no-]progress on the command line, which feels somewhat satisfying. Thanks.
