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

On Wed, Sep 02, 2009 at 01:59:08PM -0400, Jeff King wrote:

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

quoted

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.

quoted

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).

Nah, you're right.
Being crotchety and hating change is a good thing here.

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?

quoted

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

The only use case would be for --amend.
Which is why I asked about --porcelain; really what I want is
something like

	git status --porcelain HEAD^

Rolling a patch to make --porcelain an alias for --short seems
like a good idea.  If we want to support HEAD^ and HEAD^ only
then perhaps an --amend flag is useful.

The real crux of my question was about being able to script
it, which is why commit --dry-run is not enough.

-- 

	David