Jeff King <p...@peff.net> writes:
>> But I think we are doing users a disservice by listing tons of
>> paths. Where the difference of versions matters _most_ is when the
>> user has tons of removed paths in the working tree. Either with one
>> warning per path, or a block of collected paths at the end, we are
>> scrolling the more important part of the message up.
> I'm not sure I agree. Even with a handful, it made me wonder why one was
> mentioned and not others. That _could_ be cleared up by rewording (i.e.,
> making it clear that this is an example, and there may be more). But
> somehow listing them is what I would expect. Perhaps because it gives
> the user a clue about what to do next; they ask themselves "did I want
> those updated or not?".
> In the orphaned-commit message when leaving a detached HEAD, we collect
> the answer, say "you are leaving N commits", and show the first 5 five
> of them, with an ellipsis at the end if we didn't show them all. Would
> it makes sense to do that here?
Because this is to help people who are _used_ to seeing "git add"
not take the removals into account, I doubt that "Did I want those
updated or not? Let me see the details of them." will be the
question they will be asking [*1*].
*1* "I know I didn't want to include these removals to the index,
but I learned today that in later Git I should make myself more
clear if I want to keep doing so; thanks for letting me know.", or
"I've long been assuming that I have to say 'git add' and 'git rm'
separately, but I learned today that I can say 'add --all', and in
later Git I do not even have to; thanks for letting me know." are
the two reactions I expected.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html