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:53:49 -0700 Message-ID: <87d4vysayq.wl%cworth@cworth.org> References: <11912513203420-git-send-email-tom@u2i.com> <7vr6ker1lf.fsf@gitster.siamese.dyndns.org> <550f9510710011441t1eb50352ofc8db77f79d794d5@mail.gmail.com> <87ejgescnb.wl%cworth@cworth.org> <550f9510710011521s126ca747v956a6f80182444bb@mail.gmail.com> <20071001223050.GE2137@spearce.org> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Mon_Oct__1_15:53:49_2007-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: Tom Clarke , Junio C Hamano , Johannes.Schindelin@gmx.de, git@vger.kernel.org To: "Shawn O. Pearce" X-From: git-owner@vger.kernel.org Tue Oct 02 00:54:23 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 1IcU9N-0007nO-JG for gcvg-git-2@gmane.org; Tue, 02 Oct 2007 00:54:06 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751781AbXJAWx5 (ORCPT ); Mon, 1 Oct 2007 18:53:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751707AbXJAWx5 (ORCPT ); Mon, 1 Oct 2007 18:53:57 -0400 Received: from olra.theworths.org ([82.165.184.25]:58898 "EHLO olra.theworths.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751082AbXJAWx4 (ORCPT ); Mon, 1 Oct 2007 18:53:56 -0400 Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id C3899431FB0; Mon, 1 Oct 2007 15:53:55 -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 KZ4xHfTAIG3i; Mon, 1 Oct 2007 15:53:51 -0700 (PDT) Received: from raht.cworth.org (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 30F85431FB3; Mon, 1 Oct 2007 15:53:50 -0700 (PDT) In-Reply-To: <20071001223050.GE2137@spearce.org> 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:53:49_2007-1 Content-Type: text/plain; charset=US-ASCII On Mon, 1 Oct 2007 18:30:50 -0400, "Shawn O. Pearce" wrote: > `git pull -s ` takes any merge strategy that git-merge will > accept for its -s option. There is also the config option of > pull.twohead that indicates what the default merge/pull strategy > should be for a two head merge. Most people don't set this, > letting the code default to 'recursive'. Ah, "pull.twohead". I don't think I ever would have guessed that. (And I was just about to ask if there was a nice place to find all these options, but then found it myself on my first guess with "man git-config". Thanks everyone for writing that!). > But I have to agree with (was it Junio who said this?) doing a rebase > in a merge strategy doesn't make sense when conflicts come into play. Sure. Rebase alone isn't useful as a complete merge strategy. But a rebase strategy that simply fails in the face of a conflict, (deferring to a subsequent merge strategy), could be very useful. > It gets confusing fast for the end-user as the conflict resolution > process is different than for a merge. A long time ago I wrote a > git-merge-rebase strategy and gave up on it for basically the same > reason. I posted it to the mailing list and I think Linus said > "Why?!". That was the end of that thread as I wound up agreeing > with him. Yes, I thought I recalled seeing a rebase strategy go by in the past, but I had never gotten around to trying it out. I'll try to do better on this try. > Multiple merge strategies can be given (and attempted). A rebase > strategy could be attempted before recursive, and if the rebase > fails but the recursive succeeds then you get (roughly) what is > being described above by Carl. But that still requires a rebase > merge strategy. :-\ Yes, this sounds exactly like what I want. So, I put "rebase recursive" in place as the value for the pull.twohead configuration? An then make sure that the rebase strategy aborts as "failed" instead of "conflicted and left for user to resolve"? I saw Junio talking about return values up above in the thread but didn't pay attention to details, (2 vs. 1 or something)? Has anyone tried this rebase then recursive strategy yet? I'm definitely interested in trying it out, as I think I'd find it quite nice as a default for pull in my usage. Though actually I'd like it even more if there was some way to mark a commit as having been "published" and the rebase strategy would refuse to rebase published commits. Maybe that's a per-branch "last-published" reference? I think I'd even like git-push to update the last-published reference for each pushed branch by default, but then perhaps have an option to mark a particular remote so that pushing to that remote doesn't count as publishing. -Carl --pgp-sign-Multipart_Mon_Oct__1_15:53:49_2007-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHAXp96JDdNq8qSWgRAqMjAKCP0NpSTh4w8siERwVzbF/quFCyiQCcDPka zgZ3nQqgZRX3DP1GW0Z13ZU= =PiXz -----END PGP SIGNATURE----- --pgp-sign-Multipart_Mon_Oct__1_15:53:49_2007-1--