Re: [PATCH 0/3] detecting delete/modechange conflicts
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
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
[PATCH 0/3] detecting delete/modechange conflicts
I was surprised to find that: # base commit echo base >file && git add file && git commit -m base && # one side changes mode chmod +x file && git commit -am executable && # the other deletes the file git checkout -b other HEAD^ && git rm file && git commit -am removed && git merge master silently completes the merge, dropping the mode change. We detect delete/modify conflicts, but not delete/modechange conflicts. The trivial index merge does catch it, but both the resolve and recursive strategies resolve it silently in favor of the deletion. 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. [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