Re: "fatal: Untracked working tree file 'so-and-so' would be overwritten by merge"

On Sun, 8 Oct 2006, Junio C Hamano wrote:

Note note note.  The above patch alone leaves merge risky to
remove an untracked working tree files, and needs to be
compensated by corresponding checks to the git-merge-xxx
strategies.  The original code was overcautious, but was
protecting valid cases too.

I think the difference _should_ be that we only remove the local file if 
it was removed _remotely_.

In  that case, it was there in the original tree, and removing it is 
correct.

So I actually think that we should NOT consider these three cases to be 
the same.

There are really two distinct cases:

 - "$1.." and "$1.$1"
	The file had already been removed locally, AND WE SHOULD NOT TOUCH 
	IT.

 - "$1$1.":
	The file was removed remotely, and we SHOULD remove it locally.

In fact, we already have that as a "special case":

 	if [ "$2" ]; then
 		echo "Removing $4"
+	elif test -f "$4"
+		echo "ERROR: untracked $4 is removed by the merge."
+		exit 1
 	fi
 	if test -f "$4"; then
 		rm -f -- "$4" &&

That

	if [ "$2" ]; then
		echo "Removing $4"

is _exactly_ that case: it is the "$1$1." case, and we already treat it 
differently, but we actually treat it differently the wrong way: we only 
print out the message for that case, but the actual "touch working tree" 
code should _also_ be affected.

If the local index doesn't change, we should not print out the "Removing 
'so-and-so'" message, but we should also not even _touch_ that file, 
because it was already "gone" as far as the local tree was concerned.

Agreed?

		Linus