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

Jeff King [off-list ref] writes:

I think "related things together" trumps "close to the bottom". Because
the former is something that _always_ applies to your output, while the
latter is catering to a particular use case and a particular screen
setup.

In other words, why is the _bottom_ reserved for more important things
instead of the _top_? If I have a tall terminal that is long enough to
see the output, are you potentially making the important thing less
obvious (because I tend to read the the output from top to bottom)? If I
use a pager (either manually, because I have seen that the output is too
long, or automatically via the pager.status config variable)? What about
reading status output into an interface wrapper like "tig status"?

Yes and no.

Sure, I always work in a 92x70 screen session with 10k lines of scrollback
buffer, and when I cut and paste I do not use a mouse but use screen's cut
buffer, so I would have no problem with the list at the top.

Not that I would use "git status" while resolving merges---I would use
"ls-files -u" myself, and I may perhaps start using "status -suno", so my
personal preference does not really count on this topic.

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.

J6t made a good point that this new section won't appear when committing,
which I didn't take account when I was first explained how the ordering
was chosen.  After thinking about this a bit more, I think "untracked" and
"modified but not updated" sections, unlike when recording your own
commit, is mostly uninteresting while resolving a merge.  You never add
files that you forgot to add to a merge; nor you would add your local
modifications to a merge.  So the only sections that are interesting are
this new "unmerged" section and "updated" section to see the extent of
damage the merge causes to your history by introducing the crap other
people dumped on you ;-) [*1*].

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?

Incidentally that is where J6t's first patch was.  So I would agree with
the patch (but not necessarily with its justification).

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