From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Schindelin Subject: Re: [PATCH v2] Teach 'git pull' about --rebase Date: Thu, 29 Nov 2007 00:16:09 +0000 (GMT) Message-ID: References: <27E5EF3C-19EF-441C-BB12-0F5B29BEAEDB@midwinter.com> <8c5c35580711281310h8764a33pba48e65010abf859@mail.gmail.com> <7vhcj63uhw.fsf@gitster.siamese.dyndns.org> <20071128223339.GF7376@fieldses.org> <20071128224717.GG7376@fieldses.org> <7v1waa2bfi.fsf@gitster.siamese.dyndns.org> <20071128235633.GI7376@fieldses.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Junio C Hamano , Lars Hjemli , Steven Grimm , Linus Torvalds , git@vger.kernel.org To: "J. Bruce Fields" X-From: git-owner@vger.kernel.org Thu Nov 29 01:16:47 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 1IxX59-0003Ue-Ls for gcvg-git-2@gmane.org; Thu, 29 Nov 2007 01:16:44 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761996AbXK2AQX (ORCPT ); Wed, 28 Nov 2007 19:16:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1761987AbXK2AQX (ORCPT ); Wed, 28 Nov 2007 19:16:23 -0500 Received: from mail.gmx.net ([213.165.64.20]:35424 "HELO mail.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1761653AbXK2AQW (ORCPT ); Wed, 28 Nov 2007 19:16:22 -0500 Received: (qmail invoked by alias); 29 Nov 2007 00:16:20 -0000 Received: from unknown (EHLO openvpn-client) [138.251.11.103] by mail.gmx.net (mp010) with SMTP; 29 Nov 2007 01:16:20 +0100 X-Authenticated: #1490710 X-Provags-ID: V01U2FsdGVkX189rI8aw0E9uIpEmXqad77PEmsXnLwsqHdYwQORLW EH1s08kDdES6dh X-X-Sender: gene099@racer.site In-Reply-To: <20071128235633.GI7376@fieldses.org> X-Y-GMX-Trusted: 0 Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: Hi, On Wed, 28 Nov 2007, J. Bruce Fields wrote: > On Wed, Nov 28, 2007 at 03:32:49PM -0800, Junio C Hamano wrote: > > Johannes Schindelin writes: > > > > > So my rationale was: if we already have an existing framework to integrate > > > remote changes with our current branch, why not just go ahead and use it? > > > That's the reason BTW why I originally wanted a "rebase" merge stragegy. > > > Even if it is not technically a merge. > > > > > > I really rather have no user-friendly support for fetch+rebase (and utter > > > a friendly, but loud curse everytime I made a "git pull" by mistake) than > > > yet another command. > > > > I suspect that people who do not like the two modes of checkout will > > certainly not appreciate the overloading two behaviours to create > > different kind of histories and two different ways to continue when the > > integration do not go smoothly upon conflicts these two behaviours have. > > > > However, I agree very much with an earlier comment made by Daniel about > > our UI being task oriented instead of being command oriented, and I > > actually consider it a good thing. So it does not bother me too much > > that "git pull --rebase" has a quite different workflow from the regular > > "merge" kind of pull. > > > > So let's queue "pull --rebase" and see what happens. > > What I'm really most worried about isn't the commandline switch but the > config option--it makes the same commandlines silently behave in very > different ways. > > I really don't want every tutorial that mentions "git pull" to have to > say "the following applies only if git..rebase is > false". And it'll be either that or risk having a lot of people saying > "I typed in exactly that commandline, but this happened....". > > A default to "false" does at least require positive acknowledgement, but > if this is expected to be used by newbies, they're going to be told to > set that config before they understand the difference it makes. Hey, why not just special case "mergeOptions = rebaseInstead"? Ciao, Dscho