On Mon, Nov 23, 2009 at 11:43:19AM -0500, Jeff King wrote: > On Mon, Nov 23, 2009 at 04:50:43PM +0100, Petr Baudis wrote: > > > On Mon, Nov 23, 2009 at 10:00:00AM -0500, Jeff King wrote: > > > The patch for (1) would look something like what's below. It's simpler, > > > but it does change the semantics; anyone who was relying on > > > --all-progress to turn on progress unconditionally would need to now > > > also use --progress. However, turning on progress unconditionally is > > > usually an error (the except is if you are piping output in real-time to > > > the user and need to overcome the isatty check). > > > > I'm actually doing exactly that in the mirrorproj.cgi of Girocco, so I > > would be unhappy if I would have to go through creating ptys or whatever > > now. Maybe conditioning this by an environment variable? > > You wouldn't need to do anything that drastic. You would just need to > pass "--progress --all-progress" instead of only --all-progress. But you > have provided the data point that such a change would break at least one > user. > > We could also leave --all-progress as-is and add new option to mean "if > you are already doing progress, do all progress". Hmm, maybe I'm confused - I just call git remote update and don't pass any progress switches - would your change still affect me? Can I pass --progress to `git remote update`? -- Petr "Pasky" Baudis A lot of people have my books on their bookshelves. That's the problem, they need to read them. -- Don Knuth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html