Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

[Junio C Hamano <gitster@pobox.com>]

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

I dunno.


[Footnote]

*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.