From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Worth Subject: Re: [PATCH] Adding rebase merge strategy Date: Mon, 01 Oct 2007 15:17:28 -0700 Message-ID: <87ejgescnb.wl%cworth@cworth.org> References: <11912513203420-git-send-email-tom@u2i.com> <7vr6ker1lf.fsf@gitster.siamese.dyndns.org> <550f9510710011441t1eb50352ofc8db77f79d794d5@mail.gmail.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Mon_Oct__1_15:17:18_2007-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: "Junio C Hamano" , Johannes.Schindelin@gmx.de, git@vger.kernel.org To: "Tom Clarke" X-From: git-owner@vger.kernel.org Tue Oct 02 00:17:40 2007 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1IcTa7-0004PB-DJ for gcvg-git-2@gmane.org; Tue, 02 Oct 2007 00:17:39 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754348AbXJAWRc (ORCPT ); Mon, 1 Oct 2007 18:17:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753578AbXJAWRb (ORCPT ); Mon, 1 Oct 2007 18:17:31 -0400 Received: from olra.theworths.org ([82.165.184.25]:54900 "EHLO olra.theworths.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753671AbXJAWRa (ORCPT ); Mon, 1 Oct 2007 18:17:30 -0400 Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 4B541431FB3; Mon, 1 Oct 2007 15:17:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vI9ERtI0yPuN; Mon, 1 Oct 2007 15:17:29 -0700 (PDT) Received: from raht.cworth.org (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 01E46431FB1; Mon, 1 Oct 2007 15:17:28 -0700 (PDT) In-Reply-To: <550f9510710011441t1eb50352ofc8db77f79d794d5@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.4 Mule/5.0 (SAKAKI) Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: --pgp-sign-Multipart_Mon_Oct__1_15:17:18_2007-1 Content-Type: text/plain; charset=US-ASCII On Mon, 1 Oct 2007 23:41:56 +0200, "Tom Clarke" wrote: > Thanks for the ample feedback, you raise a number of interesting > issues. I am wondering now if making rebase a merge strategy is really > a good idea. Rebasing is not merging, a difference that could perhaps > be overlooked in the no-conflict scenario, but as you point out, is > glaringly obvious as soon as you have conflicts. What I think I've always wanted is something like the following behavior for "git pull": * Fast forward if possible * Otherwise, rebase, but only if there are no conflicts at all * Otherwise, do the merge as normal, (leave conflict markers in place allowing the user to fix them up and then commit). Would it be straightforward to turn your rebase merge strategy into something like the above? And if so, would that address the primary concerns that Junio raised? -Carl --pgp-sign-Multipart_Mon_Oct__1_15:17:18_2007-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHAXH46JDdNq8qSWgRAlYbAKCYVnNKo/NhSzIixyobThEYQg7JnQCgpVCn DIMppZVCPpgEQeenQZsBVqw= =DK8F -----END PGP SIGNATURE----- --pgp-sign-Multipart_Mon_Oct__1_15:17:18_2007-1--