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