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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 2, 2009, 00:18 UTC
Message-ID: <7vtyzmxkpr.fsf@alter.siamese.dyndns.org>
In-Reply-To: <200909012325.45739.j6t@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

Show 14 quoted lines

> The list of unmerged files is considered rather important because after
> a conflicted merge they need attention. Since the output of git status does
> not go through the pager, the end of the output remains immediately visible
> in the terminal window. By placing unmerge entries at the end of the list,
> the user can see them immediately.
>
> Moreover, keeping the unmerge entries at the top is inconvenient if a merge
> touched many files, but only a few conflicted: After the conflicts were
> resolved, the user will conduct a 'git add' command. In order to do that
> with copy-and-paste, the user must scroll the terminal window up, and must
> do so for each individual entry (because terminal windows commonly scroll
> down automatically on the paste operation to make the cursor visible).
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>

Show 8 quoted lines

> On Dienstag, 1. September 2009, Junio C Hamano wrote:
>
>> I actually was expecting that you would move this at the very bottom after
>> untracked list for the above reason, and also because this part is only
>> shown while running status (that was a good point you made in the previous
>> message) and never in commit.
>
> So you would not mind a more "drastic" change?

Well, it's not really about what _I_ like or mind. It is primarily about what the list collectively thinks. I'd like to let other eyeballs and brains to weigh in, as I am known to pick the worst layout from the UI point of view as you saw in this thread already ;-).

> (Originally I didn't dare to change too much and thought keeping staged
> files together would make sense.)

Yes, unmerged ones are modified and the index knows about them, but you haven't told git what you want to commit yet, so they are in the same category as "changed but not updated" in that sense, but unlike "changed but not updated", you cannot leave them as they are before proceeding, so they are worse.

The "keeping related things together" argument does mean your v1 is better than this patch, as you had "unmerged" next to "changed but not updated". I personally think the "keep related things together" argument makes much more sense than the "close to the bottom is easier to cut and paste" argument, as I tend to focus at the top of the output when looking at the status output and almost never cut & paste using mouse (screen for rectangular cutting and pasting works wonderfully), but it probably is just me. And remember that I am only just one of the users, nothing more.

Sadly, "keep related things together" and "as close to the bottom as possible" are not quite compatible, and we can pick one or the other, but not both.

If I were to pick the middle ground, I would probably move it immediately after the call to wt_status_print_changed(), with "keeping related things together" as the primary justification. It would be an incidental benefit that it moves the part slightly closer to the bottom and gives it a better chance of staying on the screen.

But I am not a great UI designer ;-)