Re: [PATCH 3/3] git-commit.sh: convert run_status to a C builtin

[Junio C Hamano <junkio@cox.net>]

Jeff King <peff@peff.net> 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 ;-).