Re: [RFC/WIP PATCH 1/1] merge-recursive: make file/directory conflicts easier to resolve

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 9, 2018, 20:54 UTC
Message-ID: <xmqqk1ozb6qy.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CABPp-BH8oiJ17K6OHCikAxk8Jy9M7mSA=WCVX9KosTC+p4rE4w@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 12 quoted lines

>> Of course, "git rm" and "git mv" must work sensibly, if we want this
>> change to be truly helpful--but if not, they need to be fixed ;-)
>
> That actually brings up an interesting question.  Right now, if given
> a path that appears in the index but at a stage greater than 0, git mv
> will fail with "not under version control".  Obviously, that error
> message is a lie in such a case, but what should it do?
>
> (Alternatively, if there is only one entry with stage greater than 0
> and it has no other conflicts, one could envision git mv doing the
> rename and dropping to stage 0 at the same time, but that sounds a bit
> dangerous to me.)

I do not particularly think it is "dangerous". In fact, that sort of behaviour was what I had in mind when I said "work sensibly".

When resolving a conflict that they added a new path at stage #3 to remove that path, I can say "git rm $that_path", which removes all stages of that path and make the index closer to the next commit. Or I may decide to keep that path by "git add $that_path", which adds that path at stage #0. I think "git mv $that_path $over_there" that drops that path at stage #3 to stage #0 of another path would be in line with these two.