Jeff King <peff@xxxxxxxx> writes: > On Thu, Sep 07, 2006 at 05:20:20PM -0700, Junio C Hamano wrote: > >> "status.h" and "struct status" somehow sounds too broad. >> Granted, "object.h" is also broad, but in git context "object" >> has a specific meaning. > > I agree it is quite broad (as is git-runstatus). Conceptually it's > another type of diff format, but making it a diff argument doesn't > really makes much sense. We're at least not introducing any broadness, > since there is already git-status; are we interested in fixing that > name? The command name is a name exposed to the end user. We do not currently have a command to give "repository status", and even if we had one such a specialized command for repository administrators would be called git-repository-status so git-status is definitely fine as is. I just wanted to point it out because I felt the names to programmers are slightly different matter. > wt_status? ucu_status (updated, changed, untracked)? Yeah, something along those lines. >> Very nicely done. Especially I liked that you are careful not >> to paint leading '#\t' (which is noticeable when you use reverse >> as an attribute). > > Yes. I seem to recall some issues raised about color attributes > persisting over a newline, but I can't find any reference to it now. > Using color_printf makes sure every color is 'closed' but it sometimes > includes the newline in the colorized portion. Does anybody object to > that? In a distant past I saw some terminals get confused near the edge if you do that, but these days everybody is on some sort of Xterm so it may not matter. But that would probably be nice to fix. > OK. Besides the things you mentioned, what improvements would you like > to see? Besides the things I mentioned? I dunno offhand -- otherwise I would have mentioned them ;-). - 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