Re: [PATCH v2] status: list unmerged files last

[Jeff King <peff@peff.net>]

On Wed, Sep 02, 2009 at 03:07:32AM -0700, David Aguilar wrote:

> I agree with all of this but would also add that we can have
> our cake and eat it too with respect to wanting to "keep
> similar things together" and having "unmerged near bottom".

Well, my point was that the "bottom" is not really cake, but I am not
sure anyone else agrees.

> No one has suggested this, so I figured I would.
> What do you think about this layout?
> 
> - untracked
> - staged
> - modified
> - unmerged

What about the current branch? Alternate author info? Tracking branch
relationship? Should those be at the top or bottom?

I dunno. Maybe it is just me being crotchety and hating change, but I
like the current order (though swapping it below "updated" is fine with
me).

> While I've got you guys.. I have a patch for the new 1.7
> status that makes it:
> 
> 	git status [<tree-ish>] [--] [pathspec]
> 	(it adds support for tree-ish)
> 
> I added that because I thought that the porcelain-ish short
> status output could be useful for "what does commit --amend
> do" from a script-writers' pov, and thus adding <tree-ish>
> enables git status -s HEAD^.

If you want to know "what does commit --amend do", then shouldn't you be
using "git commit --amend --dry-run" (which is what "git status" is now,
but will not be in v1.7.0)?

Are there other uses cases for arbitrary tree-ish's?

> BTW is status -s intended to be something plumbing-like;
> something we can build upon and expect to be stable?
> I'm just curious because other commands have a --porcelain
> option and I wasn't sure if this was the intent.

We mentioned a --porcelain option in other discussion, but I don't think
there is a patch. I would be in favor of --porcelain, even if it is
currently identical to --short, because then it gives us freedom to
diverge later (and in particular it gives us the freedom to let user
configuration affect what is shown).

-Peff