Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
>> It was already on my todo-list, as a friend of mine semi-beginner with
>> Git complained about the mis-advice the other day, and I had to agree.
>
> That's a useful sort of thing to put in a commit message. :)
>
>> Eventually, git could detect that conflicts have been resolved, but
>> then that would be a different message, as not only "use git commit
>> -a" could be resurected, but "Fix them up in the work tree" should be
>> dropped when it is the case.
>
> As is this --- when I wonder why code isn't a certain way, ideas for
> future work found in the description for the blamed commit are often
> helpful in explaining the current state and saving me from blind
> alleys in changing it.
Yes.
> Anyway, this is already a very good change as-is.
>
> Actually, I'd be nervous about suggesting "use git commit -a" without
> at least also saying "inspect the result or run tests" in the
> no-conflict-markers-found case. Rerere sometimes makes mistakes, and
> the result of picking one side when merging binary files can be even
> worse.
Here is how I phrased in the one queued tentatively.
-- >8 --
From: Matthieu Moy <Matthieu.Moy@xxxxxxx>
Date: Thu, 28 Aug 2014 11:46:58 +0200
Subject: [PATCH] merge, pull: stop advising 'commit -a' in case of conflict
'git commit -a' is rarely a good way to mark conflicts as resolved:
the user anyway has to go manually through the list of conflicts to
do the actual resolution, and it is usually better to use "git add"
on each files after doing the resolution.
On the other hand, using 'git commit -a' is potentially dangerous,
as it makes it very easy to mistakenly commit conflict markers
without noticing, and even worse, the user may have started a merge
while having local changes that do not overlap with it in the
working tree.
While we're there, synchronize the 'git pull' and 'git merge'
messages: the first was ending with '... and make a commit.', but
not the latter.
Eventually, git should detect that conflicts have been resolved in
the working tree and tailor these messages further. Not only "use
git commit -a" could be resurected, but "Fix them up in the work
tree" should be dropped when it happens.
Signed-off-by: Matthieu Moy <Matthieu.Moy@xxxxxxx>
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
diff --git a/advice.c b/advice.c
index 9b42033..3b8bf3c 100644
--- a/advice.c
+++ b/advice.c
@@ -86,8 +86,7 @@ int error_resolve_conflict(const char *me)
* other commands doing a merge do.
*/
advise(_("Fix them up in the work tree, and then use 'git add/rm <file>'\n"
- "as appropriate to mark resolution and make a commit, or use\n"
- "'git commit -a'."));
+ "as appropriate to mark resolution and make a commit."));
return -1;
}
diff --git a/git-pull.sh b/git-pull.sh
index 18a394f..4d4fc77 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -20,7 +20,7 @@ die_conflict () {
if [ $(git config --bool --get advice.resolveConflict || echo true) = "true" ]; then
die "$(gettext "Pull is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>'
-as appropriate to mark resolution, or use 'git commit -a'.")"
+as appropriate to mark resolution and make a commit.")"
else
die "$(gettext "Pull is not possible because you have unmerged files.")"
fi
--
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