On Thu, Jan 03, 2013 at 02:33:09PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Oh, I agree it's insane to try to carry through unmerged entries. I'm
just concerned that not all code paths are careful enough to check.
I would actually be surprised if some code path do
On Tue, Jan 01, 2013 at 02:24:46PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
So I think we need to update twoway_merge to recognize unmerged entries,
which gives us two options:
1. Reject the merge.
2. Throw away the current unmerged entry in favor of the new
Jeff King p...@peff.net writes:
Or are you suggesting that the three-way case should always be protected
by checking that there are no unmerged entries before we start it? That
seems sane to me, but I haven't confirmed that that is the case.
I think the normal (and hopefully only) -m -u O A B
On Thu, Jan 03, 2013 at 12:34:27PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Or are you suggesting that the three-way case should always be protected
by checking that there are no unmerged entries before we start it? That
seems sane to me, but I haven't confirmed that
Jeff King p...@peff.net writes:
So I think we need to update twoway_merge to recognize unmerged entries,
which gives us two options:
1. Reject the merge.
2. Throw away the current unmerged entry in favor of the new entry
(when old and new are the same, of course; otherwise we
On Sat, Dec 29, 2012 at 06:05:41AM -0500, Jeff King wrote:
[clear state from last run]
$ rm -rf .git/rebase-apply
$ git reset --hard
[apply the patch; we get a conflict]
$ git am -3sc
queue-3.2/alsa-usb-audio-fix-missing-autopm-for-midi-input.patch
[now run just the
6 matches
Mail list logo
