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

On Tue, Sep 01, 2009 at 10:26:26PM -0700, Junio C Hamano wrote:

Here is how I would justify the change (the patch is the same as Hannes's
first version.

From: Johannes Sixt <redacted>
Date: Tue, 1 Sep 2009 22:13:53 +0200
Subject: [PATCH] status: list unmerged files much later

When resolving a conflicted merge, two lists in the status output need
more attention from the user than other parts.

 - the list of updated paths is useful to review the amount of changes the
   merge brings in (the user cannot do much about them other than
   reviewing, though); and

 - the list of unmerged paths needs the most attention from the user; the
   user needs to resolve them in order to proceed.

Since the output of git status does not by default go through the pager,
the early parts of the output can scroll away at the top. It is better to
put the more important information near the bottom.  During a merge, local
changes that are not in the index are minimum, and you should keep the
untracked list small in any case, so moving the unmerged list from the top
of the output to immediately after the list of updated paths would give us
the optimum layout..

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

No one has suggested this, so I figured I would.
What do you think about this layout?

- untracked
- staged
- modified
- unmerged

This isn't the first thing someone would think of, but here's
why it is intuitive:

- untracked entries come first because in the git world they
  are weird.  We don't like to see these things and we tend to
  .gitignore them away.

- staged entries come next, though we know that in practice
  staged is often shown first since we tend to not care about
  untracked files.  This often contains entries when merging
  but we do not often do much with these besides review them.

- modified entries come next because they need our attention.
  When merging this list is often small or non-existant,
  thus unmerged often follows immediately after staged.

- unmerged comes last for all of the reasons listed above.
  We give these special treatment because they often
  require even more attention than modified files.

What do you guys think?


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

Is this a good idea?  I'll send the patch if others are
interested.  It seemed useful to me; my rationale was that
right now git-status is hardcoded to HEAD and thus exposing
that variable seemed useful.

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.


Thanks,

-- 

	David