Re: [PATCH 0/3] detecting delete/modechange conflicts

2015-10-26 Thread Jeff King
On Mon, Oct 26, 2015 at 02:46:42PM -0700, Junio C Hamano wrote:

> > After looking through the history and the list archive, I don't _think_
> > this was intentional, and we simply missed the case in both places. But
> > maybe somebody else knows something I don't. It seems like we should be
> > punting to the user under the general principle of stupid and safe
> > merges.
> 
> Yes, I do not recall ever discussing and agreeing with Linus that we
> should resolve to deletion over mode change, and I agree that it
> would be very likely that this never came up in practice simply
> because in real life removal is already rare, mode change is rarer,
> and these happening to the same path in the same timeperiod to
> matter in merges is even more rare.
> 
> We should definitely signal a conflict.

Thanks, that matches my thinking exactly.

BTW, this came up because libgit2 does signal the conflict, and we are
regression-testing a switch from merge-resolve over to libgit2 to power
GitHub's "merge" button. Run it on enough test cases and you will find
one of everything. :)

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/3] detecting delete/modechange conflicts

2015-10-26 Thread Junio C Hamano
Jeff King  writes:

> After looking through the history and the list archive, I don't _think_
> this was intentional, and we simply missed the case in both places. But
> maybe somebody else knows something I don't. It seems like we should be
> punting to the user under the general principle of stupid and safe
> merges.

Yes, I do not recall ever discussing and agreeing with Linus that we
should resolve to deletion over mode change, and I agree that it
would be very likely that this never came up in practice simply
because in real life removal is already rare, mode change is rarer,
and these happening to the same path in the same timeperiod to
matter in merges is even more rare.

We should definitely signal a conflict.

>   [1/3]: t6031: move triple-rename test to t3030
>   [2/3]: t6031: generalize for recursive and resolve strategies
>   [3/3]: merge: detect delete/modechange conflict
>
> -Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html