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

[David Aguilar <davvid@gmail.com>]

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 <j6t@kdbg.org>
> 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