Jeff King <peff@xxxxxxxx> 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. -- 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