jk/1.7.0-status, was: What's cooking in git.git (Sep 2009, #02; Mon, 07)

From: Jeff King <peff@peff.net>
Date: Sep 9, 2009, 11:59 UTC
Message-ID: <20090909115924.GA31149@coredump.intra.peff.net>
In-Reply-To: <7vtyzexnhm.fsf@alter.siamese.dyndns.org>

On Mon, Sep 07, 2009 at 05:56:53PM -0700, Junio C Hamano wrote:

Show 16 quoted lines

> * jk/1.7.0-status (2009-09-05) 5 commits
>  - docs: note that status configuration affects only long format
>   (merged to 'next' on 2009-09-07 at 8a7c563)
>  + commit: support alternate status formats
>  + status: add --porcelain output format
>  + status: refactor format option parsing
>  + status: refactor short-mode printing to its own function
>  (this branch uses jc/1.7.0-status.)
> 
> Gives the --short output format to post 1.7.0 "git commit --dry-run" that
> is similar to that of post 1.7.0 "git status".
> 
> It might be a good idea to make the --short format part of 1.6.6 without
> waiting for 1.7.0; it would require some branch shuffling to bring the
> short-status patch earlier than the one that makes "status" different from
> "commit --dry-run", though.

It looks like the short-status patch is already right before "commit --dry-run", but it is of course part of "git stat". So we could get by with branching from jc/1.7.0-status^, and do one of:

 1. develop as if we were a totally separate topic, refactoring, adding
    --porcelain mode, etc.

 2. just support "--short" from "git status" with as small a change as
    possible, and let the rest of the enhancements stay where they are,
    for 1.7.0

Option (1) is what I would usually do, but I think in this case it is just going to end up with me re-doing lots of work as the almost-duplicated refactoring happening in the two branches is going to make a gigantic conflict.

And of course option (3) is to just let --short rest until 1.7.0.

-Peff