Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > Maybe "sometimes", but to me, that's sufficiently rare to be omited > here (I don't think I ever used 'git rm' to resolve a conflict). The > user manual says this: > > ,---- > | Each time you resolve the conflicts in a file and update the index: > | > | $ git add file.txt > | > | the different stages of that file will be "collapsed", after which git > | diff will (by default) no longer show diffs for that file. > `---- > > and I don't think it makes sense to try to be more exhaustive here > than in the user-manual. I tend to disagree. The user-manual, as it currently stands, is an introductory document that covers the concepts and the surface of git. It's purpose is not to replace the main manual, but to give the necessary foundation _before_ people read the manual. >> The need to give this advice on how to resolve conflicts is shared among >> commands like 'git merge', 'git cherry-pick', and 'git status', to name a >> few. > > Not sure 'status' needs anything more. It already says > > # Unmerged paths: > # (use "git add/rm <file>..." as appropriate to mark resolution) > # > # both modified: foo.txt This message was exactly what I was getting at. The message in the parentheses is what I called "advice". As I was suggesting to share the advice messages used by commands that deal with mergy situations (like the one you added in your patch), looking at existing examples to find the best one and using that in other places would be the most effective approach. That one line we see above is concise and does mention "rm" as well. Why not use it? >> I think we should consolidate them all. > > Right, although "commit" is definitely the most important (dumb users > don't need "git merge"). Your "dumb users" don't get the unmerged error from commit, either, if they don't need "git merge". -- 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