Junio C Hamano <gitster@xxxxxxxxx> writes:
> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
>
>> - Do we want the header line also for "status -v"? (I would say yes, but that
>> would be a change to current behaviour.)
>
> I would not object to it very strongly, but I do not see a point in
> changing the behaviour.
>
> And I do not see why a new user would want it anyway. There is no
> need to differenciate the changes to be committed from the changes
> left in the working tree when the latter is not even shown.
Extending this line of thought further.
If I am reading your patch 3/3 right, "status -v -v" shows the
header when there are patches to be shown for the category. I am
not sure if that is the most helpful way for the users, when either
c/i xor i/w diffs is missing.
There are four cases, obviously ;-)
1. When there are changes to be committed:
a) When there is no change left in the working tree, the proposed
output would be the same as the more familiar "status -v"
output. Showing changes to be committed header would of course
help.
I wondered if the proposed behaviour hurts the user by hiding
the header for changes to be left out, though. By seeing that
the second header alone and no diff, the user will be assured
that there is no changes left in the working tree, forgotten to
be added. But this point is minor. As the users get used to
the behaviour of "-v -v", they will learn to read the emptyness
and find its proper meaning that there is no change left out.
So I think the proposed behaviour would be OK in this case. In
fact, not showing the second header when there is no change left
in the working tree will help potential issues with case 2-b).
b) When there is change left in the working tree, the proposed
output is fine. Two headers are shown to indicate what the
following diff is about and cleanly shows where the boundary of
the two classes are (especially if you resurrect the -{50}
separator line I suggested, at least for the second header).
2. When there is no change to be committed:
a) When there is no change left in the working tree, the proposed
output is fine. There is no output (no header, no diff), and
the user immediately knows that the working tree and the index
are clean.
b) When there are changes left in the working tree, the user sees
one header followed by a diff in the proposed output. Visually,
the single line heading (even with the separateor line) may be
so small in the context of the whole output, and the user needs
to READ it to notice that the diff being shown are not what is
going to be committed. In other words, it is too similar to the
proposed output in case 1-a).
If we show the "to be committed" header followed by no diff, and
then the second header followed by diff, it would be crystial
clear to the user, because it looks unusual, that what is shown
is different from case 1-a). This would especially be true if
you resurrected -{50} separator line after the heading.
So, my recommendation for "status -v -v" would be:
if (there are changes to be committed, or
there are changes left in the working tree) {
show "to be committed" with -{50};
show c/i diff;
}
if (there are changes left in the working tree) {
show "left in the working tree" with -{50};
show i/w diff;
}
--
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