[PATCH] fix read-tree storing wrong tree reference with modified index

[PATCH] fix read-tree storing wrong tree reference with modified index

[Heiko Voigt]

In 456156d a shortcut to priming the index tree reference was
introduced.

When read-tree is called with -m one would expect it to merge the
tree read and the existing one stored in the index. It did that
correctly but the index referenced the wrong tree. This sometimes lead
to a situation that the diff of

  index <-> HEAD       (git diff)
  index <-> worktree   (git diff --cached)

was empty but

  HEAD <-> worktree    (git diff HEAD)

did show changes because the SHA1 of the worktree files were still in
the index but the referenced tree came from HEAD. The test demonstrates
how to create such a situation.

Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---

I stumbled upon this bug when using git gui. For some reason it does not
always result in the situation described above. I am not sure whether
this is the correct fix or if we expect a different behavior from
read-tree. So another set of eyes is appreciated.

 builtin/read-tree.c         |    6 ++++--
 t/t1001-read-tree-m-2way.sh |   16 ++++++++++++++++
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/builtin/read-tree.c b/builtin/read-tree.c
index 8bdcab1..3cb6cdd 100644
--- a/builtin/read-tree.c
+++ b/builtin/read-tree.c
@@ -221,11 +221,13 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
 	 * what came from the tree.
 	 *
 	 * The same holds true if we are switching between two trees
-	 * using read-tree -m A B.  The index must match B after that.
+	 * using read-tree A B (without -m). The index must match B
+	 * after that. With given -m it can be a mix of the old index
+	 * and the read one.
 	 */
 	if (nr_trees == 1 && !opts.prefix)
 		prime_cache_tree(&active_cache_tree, trees[0]);
-	else if (nr_trees == 2 && opts.merge)
+	else if (nr_trees == 2 && !opts.merge)
 		prime_cache_tree(&active_cache_tree, trees[1]);
 
 	if (write_cache(newfd, active_cache, active_nr) ||
diff --git a/t/t1001-read-tree-m-2way.sh b/t/t1001-read-tree-m-2way.sh
index 6327d20..a5ad3c1 100755
--- a/t/t1001-read-tree-m-2way.sh
+++ b/t/t1001-read-tree-m-2way.sh
@@ -390,4 +390,20 @@ test_expect_success \
      git ls-files --stage | tee >treeMcheck.out &&
      test_cmp treeM.out treeMcheck.out'
 
+test_expect_success '-m references the correct modified tree' '
+	echo > file-a &&
+	echo > file-b &&
+	git add file-a file-b &&
+	git commit -a -m "test for correct modified tree"
+	git branch initial-mod &&
+	echo b > file-b &&
+	git commit -a -m "B" &&
+	echo a > file-a &&
+	git add file-a &&
+	git ls-tree $(git write-tree) file-a > expect &&
+	git read-tree -m HEAD initial-mod &&
+	git ls-tree $(git write-tree) file-a > actual &&
+	test_cmp expect actual
+'
+
 test_done
-- 
1.7.2.rc2.1.g8c934

Re: [PATCH] fix read-tree storing wrong tree reference with modified index

[Junio C Hamano]

Heiko Voigt <hvoigt@hvoigt.net> writes:

>  	 * The same holds true if we are switching between two trees
> -	 * using read-tree -m A B.  The index must match B after that.
> +	 * using read-tree A B (without -m). The index must match B
> +	 * after that. With given -m it can be a mix of the old index
> +	 * and the read one.

I think the justification of the original patch is completely bogus.  Why
not just drop the priming instead?  Two-tree read-tree without -m does not
make much sense but the result would look like an overlay of two trees,
and is not likely to match either of the trees.

Re: [PATCH] fix read-tree storing wrong tree reference with modified index

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Heiko Voigt <hvoigt@hvoigt.net> writes:
>
>>  	 * The same holds true if we are switching between two trees
>> -	 * using read-tree -m A B.  The index must match B after that.
>> +	 * using read-tree A B (without -m). The index must match B
>> +	 * after that. With given -m it can be a mix of the old index
>> +	 * and the read one.
>
> I think the justification of the original patch is completely bogus.  Why
> not just drop the priming instead?  Two-tree read-tree without -m does not
> make much sense but the result would look like an overlay of two trees,
> and is not likely to match either of the trees.

IOW, how about doing this (backported to 1.6.4 codebase) instead?

-- >8 --
Subject: [PATCH] Fix "read-tree -m A B" priming the cache-tree

In 456156d a shortcut to priming the index tree reference was
introduced, but the justification for it was completely bogus.

"read-tree -m A B" is to take the index (and the working tree)
that is largely based on (but does not have to match exactly) A
and update it to B, while carrying the local change that does
not overlap the difference between A and B, so there is no reason
to expect that the resulting index should match the tree B.

Noticed and test provided by Heiko Voigt.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin-read-tree.c         |    5 -----
 t/t1001-read-tree-m-2way.sh |   16 ++++++++++++++++
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 82e25ea..4fbf5f8 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -199,14 +199,9 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
 	 * "-m ent" or "--reset ent" form), we can obtain a fully
 	 * valid cache-tree because the index must match exactly
 	 * what came from the tree.
-	 *
-	 * The same holds true if we are switching between two trees
-	 * using read-tree -m A B.  The index must match B after that.
 	 */
 	if (nr_trees == 1 && !opts.prefix)
 		prime_cache_tree(&active_cache_tree, trees[0]);
-	else if (nr_trees == 2 && opts.merge)
-		prime_cache_tree(&active_cache_tree, trees[1]);
 
 	if (write_cache(newfd, active_cache, active_nr) ||
 	    commit_locked_index(&lock_file))
diff --git a/t/t1001-read-tree-m-2way.sh b/t/t1001-read-tree-m-2way.sh
index 271bc4e..6e3b601 100755
--- a/t/t1001-read-tree-m-2way.sh
+++ b/t/t1001-read-tree-m-2way.sh
@@ -392,4 +392,20 @@ test_expect_success \
      git ls-files --stage | tee >treeMcheck.out &&
      test_cmp treeM.out treeMcheck.out'
 
+test_expect_success '-m references the correct modified tree' '
+	echo >file-a &&
+	echo >file-b &&
+	git add file-a file-b &&
+	git commit -a -m "test for correct modified tree"
+	git branch initial-mod &&
+	echo b >file-b &&
+	git commit -a -m "B" &&
+	echo a >file-a &&
+	git add file-a &&
+	git ls-tree $(git write-tree) file-a >expect &&
+	git read-tree -m HEAD initial-mod &&
+	git ls-tree $(git write-tree) file-a >actual &&
+	test_cmp expect actual
+'
+
 test_done
-- 
1.7.2.rc2.191.gd2de1

Re: Re: [PATCH] fix read-tree storing wrong tree reference with modified index

[Heiko Voigt]

On Thu, Jul 08, 2010 at 05:45:28PM -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Heiko Voigt <hvoigt@hvoigt.net> writes:
> >
> >>  	 * The same holds true if we are switching between two trees
> >> -	 * using read-tree -m A B.  The index must match B after that.
> >> +	 * using read-tree A B (without -m). The index must match B
> >> +	 * after that. With given -m it can be a mix of the old index
> >> +	 * and the read one.
> >
> > I think the justification of the original patch is completely bogus.  Why
> > not just drop the priming instead?  Two-tree read-tree without -m does not
> > make much sense but the result would look like an overlay of two trees,
> > and is not likely to match either of the trees.

If you say so I believe you. I was searching for the reason anyway.

> IOW, how about doing this (backported to 1.6.4 codebase) instead?

Looks good to me (from what I understand).

For the test code you can add my

Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>


> -- >8 --
> Subject: [PATCH] Fix "read-tree -m A B" priming the cache-tree
> 
> In 456156d a shortcut to priming the index tree reference was
> introduced, but the justification for it was completely bogus.
> 
> "read-tree -m A B" is to take the index (and the working tree)
> that is largely based on (but does not have to match exactly) A
> and update it to B, while carrying the local change that does
> not overlap the difference between A and B, so there is no reason
> to expect that the resulting index should match the tree B.
> 
> Noticed and test provided by Heiko Voigt.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  builtin-read-tree.c         |    5 -----
>  t/t1001-read-tree-m-2way.sh |   16 ++++++++++++++++
>  2 files changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/builtin-read-tree.c b/builtin-read-tree.c
> index 82e25ea..4fbf5f8 100644
> --- a/builtin-read-tree.c
> +++ b/builtin-read-tree.c
> @@ -199,14 +199,9 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
>  	 * "-m ent" or "--reset ent" form), we can obtain a fully
>  	 * valid cache-tree because the index must match exactly
>  	 * what came from the tree.
> -	 *
> -	 * The same holds true if we are switching between two trees
> -	 * using read-tree -m A B.  The index must match B after that.
>  	 */
>  	if (nr_trees == 1 && !opts.prefix)
>  		prime_cache_tree(&active_cache_tree, trees[0]);
> -	else if (nr_trees == 2 && opts.merge)
> -		prime_cache_tree(&active_cache_tree, trees[1]);
>  
>  	if (write_cache(newfd, active_cache, active_nr) ||
>  	    commit_locked_index(&lock_file))
> diff --git a/t/t1001-read-tree-m-2way.sh b/t/t1001-read-tree-m-2way.sh
> index 271bc4e..6e3b601 100755
> --- a/t/t1001-read-tree-m-2way.sh
> +++ b/t/t1001-read-tree-m-2way.sh
> @@ -392,4 +392,20 @@ test_expect_success \
>       git ls-files --stage | tee >treeMcheck.out &&
>       test_cmp treeM.out treeMcheck.out'
>  
> +test_expect_success '-m references the correct modified tree' '
> +	echo >file-a &&
> +	echo >file-b &&
> +	git add file-a file-b &&
> +	git commit -a -m "test for correct modified tree"
> +	git branch initial-mod &&
> +	echo b >file-b &&
> +	git commit -a -m "B" &&
> +	echo a >file-a &&
> +	git add file-a &&
> +	git ls-tree $(git write-tree) file-a >expect &&
> +	git read-tree -m HEAD initial-mod &&
> +	git ls-tree $(git write-tree) file-a >actual &&
> +	test_cmp expect actual
> +'
> +
>  test_done
> -- 
> 1.7.2.rc2.191.gd2de1
>