From: Junio C Hamano <gitster@pobox•com>
To: git@vger•kernel.org
Subject: [RFC] improving advice message from "git commit" during a merge
Date: Wed, 27 Aug 2014 11:23:08 -0700 [thread overview]
Message-ID: <xmqq4mwxeqr7.fsf@gitster.dls.corp.google.com> (raw)
When there are unmerged paths, you would often get something like
this:
[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...
next reply other threads:[~2014-08-27 18:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-27 18:23 Junio C Hamano [this message]
2014-08-27 19:18 ` [RFC] improving advice message from "git commit" during a merge Jeff King
2014-08-27 19:28 ` Junio C Hamano
2014-08-28 9:46 ` [PATCH] merge, pull: stop advising 'commit -a' in case of conflict Matthieu Moy
2014-08-28 17:28 ` Junio C Hamano
2014-08-28 17:41 ` Matthieu Moy
2014-08-28 18:16 ` Jonathan Nieder
2014-08-28 18:36 ` Junio C Hamano
2014-08-29 6:44 ` Matthieu Moy
2014-08-28 12:17 ` [RFC] improving advice message from "git commit" during a merge Stefan Beller
2014-08-28 17:11 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq4mwxeqr7.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox