When I've done a merge that got conflicts, I fix up the conflicts,
then git add and git rm files as appropriate; git add is silent (even
if there are further files in need of attention) but git rm nags me
about files that still need merged and reports which files it is
removing.  The minor inconsistency here (add is silent, rm is chatty,
by default) is a blemish, but endurable.

More irritatingly, git rm even nags about the files I've told it to
remove, before telling me that it's removing them.  This nagging
serves no purpose, other than to spam my command-line and move
meaningful output further up my scroll-space and closer to the top of
what I can scroll back to.  I told it to remove the files: it should
not be nagging me about the fact that I need to do something about
them - it should know that I *am* doing something about them !

It is reasonable to report what files are being removed, it is even
reasonable to nag me about files still in need of conflict resolution
after the removals (albeit the hobgoblin of small minds would be
happier of if rm and add behaved the same on this); but nagging me
about the need to sort out a file I *am* sorting out, by the git rm
command being executed, is pure wanton irritant.

It would make sense for git rm's nagging to happen *after* it has done
its removals: information about it doing what I told it to do is less
interesting than information about what I need to do next, so it makes
sense for the nagging to appear last in the output; and doing the
check, for what to nag about, *after* the removals would avoid the
spam.

Hi,

Edward Welbourne wrote:
[...]

Could you provide some sample output?  Yes, I know I can do it
myself, but I am lazy. :)

eddy@pool:work$ git merge origin/topic-branch-blah
Renaming stuff/parts/foobar.txt => stuff/parts/burble.txt
Auto-merging stuff/parts/burble.txt
CONFLICT (rename/modify): Merge conflict in stuff/parts/burble.txt
CONFLICT (delete/modify): stuff/parts/frobnotz.txt deleted in HEAD and modified in origin/topic-branch-blah. Version origin/topic-branch-blah of stuff/parts/frobnotz.txt left in tree.
Recorded preimage for 'stuff/parts/burble.txt'
Automatic merge failed; fix conflicts and then commit the result.
eddy@pool:work$ emacs stuff/parts/burble.txt
eddy@pool:work$ git add stuff/parts/burble.txt
eddy@pool:work$ git rm stuff/parts/frobnotz.txt
stuff/parts/frobnotz.txt: needs merge
rm 'stuff/parts/frobnotz.txt'

</quote> (Based on an archived emacs M-x shell session from a real
merge, but with large amounts of extraneous material deleted and the
survivors renamed mercilessly.  Obviously, I didn't actually invoke
emacs from that command-line ...)

Notice that I'm told frobnotz.txt needs merge by the very command in
which I resolve its conflicts.  Notice that the comparatively complex
situation with burble.txt (where my work branch has renamed foobar.txt
to it but the topic branch hadn't) is handled more gracefully.

	Eddy.

Edward Welbourne wrote:

I agree that this is ugly.  Please feel free to send a patch
eliminating both messages to git@vger.kernel.org (cc-ing me), in case
I do not get around to it first.

There's some advice for prospective patch authors in
Documentation/SubmittingPatches.

Thanks again for the report.