Re: [PATCH v6 3/4] reset: add a few tests for "git reset --merge"
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 1, 2010, 05:15 UTC
- Message-ID
- <7v7hs2o16j.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20091230055448.4475.42383.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
Show 11 quoted lines
> Commit 9e8eceab ("Add 'merge' mode to 'git reset'", 2008-12-01),
> added the --merge option to git reset, but there were no test cases
> for it.
>
> This was not a big problem because "git reset" was just forking and
> execing "git read-tree", but this will change in a following patch.
>
> So let's add a few test cases to make sure that there will be no
> regression.
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>Looks good.
Show 30 quoted lines
> +# The next test will test the following: > +# > +# working index HEAD target working index HEAD > +# ---------------------------------------------------- > +# file1: C C C D --merge D D D > +# file2: C D D D --merge C D D > +test_expect_success 'reset --merge is ok with changes in file it does not touch' ' > + git reset --merge HEAD^ && > + ! grep 4 file1 && > + grep 4 file2 && > + test "$(git rev-parse HEAD)" = "$(git rev-parse initial)" && > + test -z "$(git diff --cached)" > +' > ... > +# The next test will test the following: > +# > +# working index HEAD target working index HEAD > +# ---------------------------------------------------- > +# file1: C C C D --merge D D D > +# file2: C C D D --merge D D D > +test_expect_success 'reset --merge discards changes added to index (2)' ' > + git reset --hard second && > + echo "line 4" >> file2 && > + git add file2 && > + git reset --merge HEAD^ && > + ! grep 4 file2 && > + test "$(git rev-parse HEAD)" = "$(git rev-parse initial)" && > + test -z "$(git diff)" && > + test -z "$(git diff --cached)" > +'
These two seem to duplicate the same case for file1; is it necessary?
I am not pointing it out as something that needs to be removed; I am just puzzled and wondering if there is some interaction between the ways two paths are handled and the test is trying to check that (which I do not think is the case).