Thomas Rast [off-list ref] writes:
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 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 deleted).
Perhaps making sure the index is empty is sufficient, then?
On Thu, Jun 20, 2013 at 11:43:37AM -0700, Junio C Hamano wrote:
Thomas Rast [off-list ref] writes:
quoted
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 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 deleted).
Perhaps making sure the index is empty is sufficient, then?
That would not let you pull when you have "foo" staged, but upstream
does not have "foo" at all. To be fair, that is quite a corner case, and
simply rejecting the pull entirely may be OK. But read-tree already does
the hard work for us, so I don't think it is a lot of code either way.
-Peff