Re: [PATCH] pull: pull into void by fast-forwarding from empty tree

[Jeff King <peff@peff.net>]

On Thu, Jun 20, 2013 at 02:36:03PM +0200, Thomas Rast wrote:

> The logic for pulling into an unborn branch was originally designed to
> be used on a newly-initialized repository (d09e79c, git-pull: allow
> pulling into an empty repository, 2006-11-16).  It thus did not
> initially deal with uncommitted changes in the unborn branch.  The
> case of an _unstaged_ untracked file was fixed by by 4b3ffe5 (pull: do
> not clobber untracked files on initial pull, 2011-03-25).  However, it
> still clobbered existing staged files, both when the file exists in
> the merged commit (it will be overwritten), and when it does not (it
> will be lost!).

Yeah, in 4beffe5 I just assumed that using "read-tree -m" would give us
the protections we need. But obviously I didn't think about the fact
that we are not giving it enough information.

> We fix this by doing a two-way merge, where the "current" side of the
> merge is an empty tree, and the "target" side is HEAD (already updated
> to FETCH_HEAD at this point).  This amounts to claiming that all work
> in the index was done vs. an empty tree, and thus all content of the
> index is precious.

This seems like the correct fix; it is giving read-tree the right
information to make the decision. Thanks for working on this.

> +test_expect_success 'pulling into void does not overwrite staged files' '
> +	git init cloned-staged-colliding &&
> +	(
> +		cd cloned-staged-colliding &&
> +		echo "alternate content" >file &&
> +		git add file &&
> +		test_must_fail git pull .. master &&
> +		echo "alternate content" >expect &&
> +		test_cmp expect file
> +	)
> +'
> +
> +test_expect_success 'pulling into void does not remove new staged files' '
> +	git init cloned-staged-new &&
> +	(
> +		cd cloned-staged-new &&
> +		echo "new tracked file" >newfile &&
> +		git add newfile &&
> +		git pull .. master &&
> +		echo "new tracked file" >expect &&
> +		test_cmp expect newfile
> +	)
> +'

Do we want to also check the index state after each pull? In the former
case, I think it should obviously represent a conflict. In the latter,
we should be retaining the index contents of newfile.

These are basic things that read-tree's two-way merge should get right
(and are presumably tested elsewhere), but it might be worth confirming
the desired behavior here in case somebody later tries to tweak this
code path not to use read-tree.

-Peff