On 5/24/07, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote:
Alex Riesen <raa.lkml@xxxxxxxxx> wrote: > On 5/24/07, skimo@xxxxxxxx <skimo@xxxxxxxx> wrote: > > >+ args[argc++] = "checkout"; > >+ if (state->force) > >+ args[argc++] = "-f"; > >+ args[argc++] = sha1_to_hex(ce->sha1); > >+ args[argc] = NULL; > > You should consider passing "-v" if the superprojects read-tree > had it. Some submodules will be annoyingly big In 1.5.2 that -v shouldn't be necessary. The read-tree should
It is necessary. Progress meters may not stay forever the only thing to show when verbose. The code just stripped a part of users command, how _can_ this be ok?!
start a timer, and if it has not reached 50% of its processing within 2 seconds it starts showing progress. Unless !istty(2), in which case it just sits there, chugging away at your drive. I'm actually really unhappy with our !istty(2) means disable progress thing. git-gui knows how to read and show the progress meters, but nobody prints them anymore as 2 is a pipe. I have the
Somebody does: just because some stupid script in the middle did a 2>&1.
same problem with a Java build tool that sometimes starts up an expensive Git operation (like a clone over SSH of a 60+ MiB project).
That said, many tools have explicit --progress switch. Maybe _this_ is what you need, and not an override whether STDERR is on a tty. BTW, you could have used ptys, at least on UNIX-like platforms. - 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
