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@xxxxxxxx> > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html