Re: unmerged files listed in the beginning of git-status

bill lam [off-list ref] writes:

I noticed in the new git 1.6.4.2 .

I hope you didn't.  This is only in 'master' and will appear first in the
upcoming 1.6.5; it is never meant for 1.6.4.X maintenance series and
1.6.4.2 does not have this change.

git-status show unmerged files
with a clause of explanation.  This is very helpful. However these
unmerged files are listed in the beginning and followed by modified
files,

"git status" is preview of what git commit does.  The "Changes to be
committed" section is given at the beginning of the output because it is
the most important one.  But while reviewing the conflicts, you would want
to notice conflicted paths more than what are already resolved and staged.

It used to be that unmerged paths were mixed together with locally
modified paths in the "Changed but not updated" list, after the "Changes
to be committed" list.  This made the unmerged paths harder to spot than
necessary.

To remedy this, unmerged ones are now:

 (1) placed in a new, separate section that appears only when there are
     unmerged paths, to make the fact that there is something unusual
     going on (i.e. conflicts) stand out; and

 (2) the new section is given at the top of the status output to give
     these unmerged paths more prominence.

Having said all that, the relative importance of the pieces of information
given in "git status" output is fairly subjective.

If you are a confident, know-what-I-am-doing type, you would see the
"Changes to be committed" list the most important, because that is where
you make sure you have added all the changes you want to include in the
commit.  If you are a forgetful type, on the other hand, you would see
"Changed but not updated" and "Untracked files" more important, because
that is where you make sure there isn't any files you modified and new
files you created that you want to include in the commit but may have
forgotten.  If you are into flipping many branches and often commit your
changes on a wrong branch, you may value the "On branch foo" information
at the top the most.  So in that sense, there cannot be a single right
order of these sections.

But unmerged entries are something you need to deal with _first_ before
being able to go further, so in that sense it is more important than
anything else in the traditional output.

In the output, "the most important part first" rule is unlikely to change,
if only because this is what you are shown when committing in the editor,
and even in 1.7.0 when "git status" stops being "git commit --dry-run"
because we would still keep consistency of the two outputs,

By the way, please do not deflect responses to your message away from
yourself using Mail-Followup-To.

On Dienstag, 1. September 2009, Junio C Hamano wrote:

bill lam [off-list ref] writes:

quoted

git-status show unmerged files
with a clause of explanation.  This is very helpful. However these
unmerged files are listed in the beginning and followed by modified
files,

"git status" is preview of what git commit does.  The "Changes to be
committed" section is given at the beginning of the output because it is
the most important one.  But while reviewing the conflicts, you would want
to notice conflicted paths more than what are already resolved and staged.

It used to be that unmerged paths were mixed together with locally
modified paths in the "Changed but not updated" list, after the "Changes
to be committed" list.  This made the unmerged paths harder to spot than
necessary.

To remedy this, unmerged ones are now:

 (1) placed in a new, separate section that appears only when there are
     unmerged paths, to make the fact that there is something unusual
     going on (i.e. conflicts) stand out; and

 (2) the new section is given at the top of the status output to give
     these unmerged paths more prominence.

But this is very inconvenient if you merge a branch that touched many files, 
of which only a few have conflicts. In this case, the unmerged entries are 
scrolled out of view. If you want to copy-paste them into a 'git add' command 
then (at least my) xterm (and Windows's CMD, BTW) keeps scrolling down to the 
command line, and since I cannot bulk-select all of them at once, I have to 
scroll up in order select any individual of them.

Note that I do not complain about the "out of view" part (because if a list is 
long there is inevitably something that becomes invisible), but about 
the "must scroll around" part.

But unmerged entries are something you need to deal with _first_ before
being able to go further, so in that sense it is more important than
anything else in the traditional output.

This is actually an argument to place the unmerged entries *last* because this 
is what will be visible after 'git status' finished. Remember that we don't 
pass its output through the pager.

In the output, "the most important part first" rule is unlikely to change,
if only because this is what you are shown when committing in the editor,
and even in 1.7.0 when "git status" stops being "git commit --dry-run"
because we would still keep consistency of the two outputs,

Of course, this argument is irrelevant for the placement of the list of 
unmerged entries because by the time you enter the commit message editor, 
this list is empty.

-- Hannes

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 after staged entries,
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 <redacted>
---
 wt-status.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/wt-status.c b/wt-status.c
index 3395456..85f3fcb 100644
--- a/wt-status.c
+++ b/wt-status.c

@@ -561,8 +561,8 @@ void wt_status_print(struct wt_status *s)
 		color_fprintf_ln(s->fp, color(WT_STATUS_HEADER, s), "#");
 	}
 
-	wt_status_print_unmerged(s);
 	wt_status_print_updated(s);
+	wt_status_print_unmerged(s);
 	wt_status_print_changed(s);
 	if (s->submodule_summary)
 		wt_status_print_submodule_summary(s);

-- 
1.6.4.2.280.gb16ab

On Tue, 01 Sep 2009, Johannes Sixt wrote:

quoted

But unmerged entries are something you need to deal with _first_ before
being able to go further, so in that sense it is more important than
anything else in the traditional output.

This is actually an argument to place the unmerged entries *last* because this 
is what will be visible after 'git status' finished. Remember that we don't 
pass its output through the pager.

If output of git-status is read indirectly such as by gui client, then
it usually shows the top portion, in such cases, it might be desirable
to put unmerged file (the most important port) immediately visible.
But I don't have that experience.

-- 
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3