On Thu, Jun 20, 2013 at 02:45:04PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > 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 mediu
Jeff King writes:
> 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.
OK, so should I consider it Reviewed-by: peff?
> As an orthogonal matt
On Thu, Jun 20, 2013 at 01:49:13PM -0700, Junio C Hamano wrote:
> > 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 th
Jeff King writes:
>> 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
On Thu, Jun 20, 2013 at 11:43:37AM -0700, Junio C Hamano wrote:
> Thomas Rast 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 d
Thomas Rast 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
Jeff King writes:
> On Thu, Jun 20, 2013 at 03:33:34PM +0200, Thomas Rast wrote:
>
>> >> I naively would have expected this to leave us in a conflicted state
>> >> over "file". But I guess read-tree just rejects it, because we are not
>> >> doing a real three-way merge. I'm not sure it is that
Thomas Rast writes:
> if test -z "$orig_head"
> then
> git update-ref -m "initial pull" HEAD $merge_head "$curr_head" &&
> - git read-tree -m -u HEAD || exit 1
> + # Two-way merge: we claim the index is based on an empty tree,
> + # and try to fast-forward to HEAD. This ensur
On Thu, Jun 20, 2013 at 03:33:34PM +0200, Thomas Rast wrote:
> >> I naively would have expected this to leave us in a conflicted state
> >> over "file". But I guess read-tree just rejects it, because we are not
> >> doing a real three-way merge. I'm not sure it is that big a deal; this
> >> is m
Thomas Rast writes:
> Jeff King writes:
>
>> On Thu, Jun 20, 2013 at 03:06:01PM +0200, Thomas Rast wrote:
>>
>>> +test_expect_success 'pulling into void does not overwrite staged files' '
>>> + git init cloned-staged-colliding &&
>>> + (
>>> + cd cloned-staged-colliding &&
>>> +
Jeff King writes:
> On Thu, Jun 20, 2013 at 03:06:01PM +0200, Thomas Rast wrote:
>
>> +test_expect_success 'pulling into void does not overwrite staged files' '
>> +git init cloned-staged-colliding &&
>> +(
>> +cd cloned-staged-colliding &&
>> +echo "alternate cont
On Thu, Jun 20, 2013 at 03:06:01PM +0200, Thomas Rast wrote:
> +test_expect_success 'pulling into void does not overwrite staged files' '
> + git init cloned-staged-colliding &&
> + (
> + cd cloned-staged-colliding &&
> + echo "alternate content" >file &&
> +
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_ untrack
13 matches
Mail list logo
