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

> Hmm. I'm getting this message annoyingly often, simply because a few files 
> that used to be tracked are now generated, and so they exist in my tree 
> but are no longer tracked.
>
> However, they may be tracked in an older tree that I pull, because in that 
> older tree they _do_ exist, and we get the
>
> 	fatal: Untracked working tree file 'so-and-so' would be overwritten by merge.
>
> which is actually incorrect, because the merge result will not even 
> _contain_ that untracked file any more.

> So the message is misleading - we should only consider this a fatal thing 
> if we actually do generate that file as part of a git-read-tree, but if a 
> merge won't touch a file, it shouldn't be "overwritten".
>
> It's true that if the _other_ end actually removed a file that we used to 
> have (ie the file _disappears_ as part of the merge), then we should 
> verify that that file matched what we're going to remove, but if the old 
> index didn't contain the file at all, and the new index won't contain it 
> either, it really should be a no-op.

> But that is a bit tricky.  This is not on the aggressive path,
> and the merge result is decided by the policy implemented by the
> caller of read-tree.  So in that sense we should not be doing
> the working tree check ourselves either.  We just should leave
> that to the caller.
>
> Hence, I think removing the above "else if" part altogether is
> the right thing to do here.
>
> ---
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 3ac0289..b1d78b8 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -661,8 +661,6 @@ int threeway_merge(struct cache_entry **
>  	if (index) {
>  		verify_uptodate(index, o);
>  	}
> -	else if (path)
> -		verify_absent(path, "overwritten", o);
>  
>  	o->nontrivial_merge = 1;
>  

> The three-way merge complained unconditionally when a path that
> does not exist in the index is involved in a merge when it
> existed in the working tree.  If we are merging an old version
> that had that path tracked, but the path is not tracked anymore,
> and if we are merging that old version in, the result will be
> that the path is not tracked.  In that case we should not
> complain.
> 
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
> 
>  * Consolidated patch to summarize a few crapoids I sent out
>    tonight.
> 
>    The change to merge-one-file still does not do .gitignore
>    check but that is easy to add once we know this is the right
>    direction to go, which I am not sure yet.  If we can convince
>    ourselves that this is the right direction we should update
>    merge-recursive as well.
> 
>  git-merge-one-file.sh       |   16 ++++++++++++-
>  t/t1004-read-tree-m-u-wf.sh |   53 +++++++++++++++++++++++++++++++++++++++++++
>  unpack-trees.c              |    2 -
>  3 files changed, 68 insertions(+), 3 deletions(-)
> 
> diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
> index fba4b0c..74ad4f2 100755
> --- a/git-merge-one-file.sh
> +++ b/git-merge-one-file.sh
> @@ -23,6 +23,12 @@ #
>  "$1.." | "$1.$1" | "$1$1.")
>  	if [ "$2" ]; then
>  		echo "Removing $4"
> +	else
> +		# read-tree checked that index matches HEAD already,
> +		# so we know we do not have this path tracked.
> +		# there may be an unrelated working tree file here,
> +		# which we should just leave unmolested.
> +		exit 0
>  	fi
>  	if test -f "$4"; then
>  		rm -f -- "$4" &&
> @@ -34,8 +40,16 @@ #
>  #
>  # Added in one.
>  #
> -".$2." | "..$3" )
> +".$2.")
> +	# the other side did not add and we added so there is nothing
> +	# to be done.
> +	;;
> +"..$3")
>  	echo "Adding $4"
> +	test -f "$4" || {
> +		echo "ERROR: untracked $4 is overwritten by the merge."
> +		exit 1
> +	}
>  	git-update-index --add --cacheinfo "$6$7" "$2$3" "$4" &&
>  		exec git-checkout-index -u -f -- "$4"
>  	;;
> diff --git a/t/t1004-read-tree-m-u-wf.sh b/t/t1004-read-tree-m-u-wf.sh
> new file mode 100755
> index 0000000..018fbea
> --- /dev/null
> +++ b/t/t1004-read-tree-m-u-wf.sh
> @@ -0,0 +1,53 @@
> +#!/bin/sh
> +
> +test_description='read-tree -m -u checks working tree files'
> +
> +. ./test-lib.sh
> +
> +# two-tree test
> +
> +test_expect_success 'two-way setup' '
> +
> +	echo >file1 file one &&
> +	echo >file2 file two &&
> +	git update-index --add file1 file2 &&
> +	git commit -m initial &&
> +
> +	git branch side &&
> +	git tag -f branch-point &&
> +
> +	echo file2 is not tracked on the master anymore &&
> +	rm -f file2 &&
> +	git update-index --remove file2 &&
> +	git commit -a -m "master removes file2"
> +'
> +
> +test_expect_success 'two-way not clobbering' '
> +
> +	echo >file2 master creates untracked file2 &&
> +	if err=`git read-tree -m -u master side 2>&1`
> +	then
> +		echo should have complained
> +		false
> +	else
> +		echo "happy to see $err"
> +	fi
> +'
> +
> +# three-tree test
> +
> +test_expect_success 'three-way not complaining' '
> +
> +	rm -f file2 &&
> +	git checkout side &&
> +	echo >file3 file three &&
> +	git update-index --add file3 &&
> +	git commit -a -m "side adds file3" &&
> +
> +	git checkout master &&
> +	echo >file2 file two is untracked on the master side &&
> +
> +	git-read-tree -m -u branch-point master side
> +'
> +
> +test_done
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 3ac0289..b1d78b8 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -661,8 +661,6 @@ int threeway_merge(struct cache_entry **
>  	if (index) {
>  		verify_uptodate(index, o);
>  	}
> -	else if (path)
> -		verify_absent(path, "overwritten", o);
>  
>  	o->nontrivial_merge = 1;
>  
> -- 
> 1.4.2.3.g2c59
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

> I think this is a good thing.
>
> How about this case I've noticed in my trees:
>
> After branching out, a file is deleted, only to add
> a different file with the same file name.
>
> Then any time I pull in from the trunk to merge,
> merge fails with git-diff-files showing all 0's and the
> file name in question.  Picture:
>
>   Branch B       +-----------------M1---->
>                 /                 /
>                C2 <-- git-add A  /
>               /                 /
>              C1 <-- git-rm A   /
>             /                 /
> Trunk -----+-----------------+---->

> Luben Tuikov <ltuikov@yahoo.com> writes:
> 
> > I think this is a good thing.
> >
> > How about this case I've noticed in my trees:
> >
> > After branching out, a file is deleted, only to add
> > a different file with the same file name.
> >
> > Then any time I pull in from the trunk to merge,
> > merge fails with git-diff-files showing all 0's and the
> > file name in question.  Picture:
> >
> >   Branch B       +-----------------M1---->
> >                 /                 /
> >                C2 <-- git-add A  /
> >               /                 /
> >              C1 <-- git-rm A   /
> >             /                 /
> > Trunk -----+-----------------+---->
> 
> Sorry I do not understand the picture; where is the common
> ancestor?  If it is the left plus sign on the Trunk line, and

> --- Junio C Hamano <junkio@cox.net> wrote:
>> Luben Tuikov <ltuikov@yahoo.com> writes:
>> 
>> > I think this is a good thing.
>> >
>> > How about this case I've noticed in my trees:
>> >
>> > After branching out, a file is deleted, only to add
>> > a different file with the same file name.
>> >
>> > Then any time I pull in from the trunk to merge,
>> > merge fails with git-diff-files showing all 0's and the
>> > file name in question.  Picture:
>> >
>> >   Branch B       +-----------------M1---->
>> >                 /                 /
>> >                C2 <-- git-add A  /
>> >               /                 /
>> >              C1 <-- git-rm A   /
>> >             /                 /
>> > Trunk -----+-----------------+---->
>> 
>> Sorry I do not understand the picture; where is the common
>> ancestor?  If it is the left plus sign on the Trunk line, and
>
> Yes, the left plus sign is the common ancestor.
>
>> you are talking about what happens when making the merge M1,
>> then before C1 A did not exist (so Trunk tip which is the right
>
> File A exists before C1, it does not exist after C1.  C1 removes
> it.

> Ah, I misunderstood.  But then I do not understand why you see
> all 0 anywhere.  Merge base has the path, branch B has it, and
> trunk has it too; wouldn't it result in regular 3-way merge?
> 
> I understand you do _not_ even want a regular 3-way merge in
> this case, but that is a separate issue.  You could write a new
> merge strategy to traverse ancestry chain between the merge base
> and each heads you are merging and notice disappearance and
> reappearance of the path, but that would slow things down
> tremendously for normal case and I do not think it is worth it.
> 
> You would also have exactly the same issue if you do not remove
> and then add the file, but if your work on the branch involves a
> significant rewrite.  Depending on how good the rewrite is,
> bugfixes that happened on the trunk based on an ancient code may
> not even be needed (in other words, it would not apply cleanly
> anyway, but it does not matter -- the branch work is much better
> or has different set of problems that the trunk fix is
> irrelevant).
> 
> At that point, M1 would involve significant merge conflicts (and
> not all-0 which I am still puzzled about), but I suspect that
> the situation is obvious enough to the human (inspect git log
> branch...trunk output and the log somewhere had better indicate
> that the are unrelated), and the solution very much is different
> case-by-case (most likely the person who pulls branch into trunk
> would say "keep ours" for the path which would mean running "git
> cat-file :2:$path >$path", or say "we are not really ready to merge
> yet" and abort the entire merge; somebody on the trunk pulling
> from that branch might say "I want other smaller fixes but this
> total rewrite is not ready yet -- keep ours", or "now we know
> this is total rewrite and the small updates on the trunk does
> not matter -- take theirs and from now on we will improve on the
> work done on the branch").
> 
> So in short, I do not think there is a clear-cut improvement we
> can do to the tools to solve this.

> 
> 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.

>  	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" &&

> 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?

> 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_.
>...
> Agreed?