Re: [PATCH v2] pull: merge into unborn by fast-forwarding from empty tree

Jeff King [off-list ref] writes:

quoted

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.

That simplicity was what I was hinting at ;-).

But read-tree already does
the hard work for us, so I don't think it is a lot of code either way.

OK, I just got an impression from reading the back-and-forth between
you two that read-tree does not want to deal with that case.

But yes, if you say "I have this index, and I am straying away from
an empty tree to that commit", with two-tree form "read-tree -m -u",
everything should work correctly, including the bit that says "nah,
nah, you have added 'foo' but the other guy also adds 'foo', so I'll
refuse".

So please scratch that short-cut suggestion.

On Thu, Jun 20, 2013 at 01:49:13PM -0700, Junio C Hamano wrote:

quoted

But read-tree already does
the hard work for us, so I don't think it is a lot of code either way.

OK, I just got an impression from reading the back-and-forth between
you two that read-tree does not want to deal with that case.

I think I got us off-track with my expectation of ending the one case
with a conflicted index. But caring about that is even more unlikely.  I
think Thomas's original patch is probably a happy medium.

As an orthogonal matter, we probably should reverse the order of
updating HEAD and the index/working tree, as it does not make much sense
to me to do the former if the latter is not possible (and that is the
case even with the current code).

-Peff