When there are unmerged paths, you would often get something like

    [git.git (pu|MERGING]$ git commit
    U       copy.c
    U       wrapper.c
    error: commit is not possible because you have unmerged files.
    hint: Fix them up in the work tree, and then use 'git add/rm <file>'
    hint: as appropriate to mark resolution and make a commit, or use
    hint: 'git commit -a'.
    fatal: Exiting because of an unresolved conflict.

which is all good and correct, but I am wondering if we can be a bit
more helpful by customizing the message in various ways.

 - When all the unmerged paths have their conflicts resolved in the
   working tree, we do not have to say "Fix them up in the work
   tree,".  We can instead say "You seem to have fixed them up in
   the work tree already," or something.

 - When some of the unmerged paths have their conflicts still in the
   working tree, we can name them separately from the ones that have
   already been dealt with.

    U       copy.c
    U       wrapper.c (conflicts already resolved in the working tree)

 - Hasty-and-careless new users will be incorrectly enticed to type
   the command given by "or use 'git commit -a'" at the end of this
   advice message without thinking.  Perhaps it is safer to stop the
   sentence at "... and make a commit." and drop that last bit while
   there are conflicts still in the working tree files.  We should
   use the current end-of-message only when all the conflicts have
   been resolved in the working tree.

 - The "/rm" in "use 'git add/rm <file>'" is often useless, as it is
   much rarer to remove a path than adding one.  Perhaps show that
   part only when there is a conflicted path with stage #2 but not
   stage #3 (i.e. they kept what we removed) or vice versa.  "add"
   needs to stay there no matter what, as that is how we tell the
   index "this is the final content".

I am not doing this myself soon, though.  Hint, hint...

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

Reply via email to