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

From: Jeff King <peff@peff.net>
Date: Sep 2, 2009, 05:12 UTC
Message-ID: <20090902051248.GB12046@coredump.intra.peff.net>
In-Reply-To: <7vmy5egefh.fsf@alter.siamese.dyndns.org>

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

Show 5 quoted lines

> But not everybody is used to such a set-up.  If you rely on terminal's
> scrollback buffer with mouse and a short terminal, I can see cutting and
> pasting would be an issue.  I do not have a good answer to "tig status",
> but the design principle of supporting the lowest denominator is
> important.

But I'm not sure it is about "lowest common denominator". I think it is about different people having different preferences (as a matter of fact, I use an 80x25 terminal most of the time, and I think I prefer the content at the top. Perhaps it is simply habit, but I do think having it right next to "staged for commit" items makes the most sense).

Show 7 quoted lines

> The above suggests me that (1) we would want to have the new "unmerged"
> section next to "updated" section, (2) we would want to have it later in
> the output rather than earlier, and (3) in the traditional output, people
> are used to see unmerged paths in "changed" section, so it would be easier
> for them to transition if "unmerged" section were near "changed" section.
> 
> That makes the ideal place between updated and changed, no?

Yes, I think that is fine, and makes more sense than where we have it now. I mainly wanted to argue against sticking it at the very bottom.

> [1] It might even make sense to omit other sections and show only
> "updated" and "unmerged" in this order when the index is unmerged, but
> that is a lot more drastic change for 1.7.0.

I think that is a really bad idea. The mental model of "git status" (versus individual diff or ls-files commands) is to see _everything_ going on in the repo. Showing a subset breaks that model and gives a false sense of what is actually happening.

I don't know that it would matter much most of the time anyway. If you have unmerged entries, you probably don't have any (or many) "changed but not updated" files, too (since you are not working on a new commit but rather a merge, they would have to be dirty state you are carrying permanently, but not related to the merge). If you do, you probably want to see them to be aware of what is going on.

You probably also don't have a lot of untracked files. If you have a few, you might want to be reminded of them to make sure they were not something you were preparing to help with a tricky merge. And if you are the sort of person who carries around a lot of untracked files, and for some reason you refuse to put them in your .gitignore, then you probably have status.untracked set to "no" already (or you should consider setting it), as they will be bugging you in other situations, as well.

-Peff