From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: git rebase -i Date: Thu, 19 Feb 2009 05:11:54 -0500 Message-ID: <20090219101154.GB16119@coredump.intra.peff.net> References: <43d8ce650902190121v2e18aac1rfaa64a4ce6e799a3@mail.gmail.com> <43d8ce650902190155m4de23643r8a9d3c35686ea4e9@mail.gmail.com> <2A7CAA9F-DB42-4782-BF61-41E8DA577DF2@wincent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: John Tapsell , Git Mailing List To: Wincent Colaiuta X-From: git-owner@vger.kernel.org Thu Feb 19 11:13:31 2009 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 1La5uM-0001hb-KB for gcvg-git-2@gmane.org; Thu, 19 Feb 2009 11:13:31 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756947AbZBSKL5 (ORCPT ); Thu, 19 Feb 2009 05:11:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756869AbZBSKL5 (ORCPT ); Thu, 19 Feb 2009 05:11:57 -0500 Received: from peff.net ([208.65.91.99]:37265 "EHLO peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754127AbZBSKL4 (ORCPT ); Thu, 19 Feb 2009 05:11:56 -0500 Received: (qmail 21525 invoked by uid 107); 19 Feb 2009 10:12:17 -0000 Received: from coredump.intra.peff.net (HELO coredump.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.40) with (AES128-SHA encrypted) SMTP; Thu, 19 Feb 2009 05:12:17 -0500 Received: by coredump.intra.peff.net (sSMTP sendmail emulation); Thu, 19 Feb 2009 05:11:54 -0500 Content-Disposition: inline In-Reply-To: <2A7CAA9F-DB42-4782-BF61-41E8DA577DF2@wincent.com> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Thu, Feb 19, 2009 at 10:59:15AM +0100, Wincent Colaiuta wrote: >> If a sample of git users would expect "git rebase -i" to let you >> rebase the last few commits, then it doesn't really matter all that >> much what N is. 10 seems a reasonable default as any. > > That's exactly the problem. Most git users aren't going to expect "git > rebase -i" to let you "rebase the last few commits". > > Rebase is mostly used, talked about, and conceptualized in terms of > rebasing onto other _branches_. Actually, I don't think that's true anymore with "rebase -i"; it is probably most convenient way in core git to rewrite the history of a patchset. E.g., a core part of my workflow as a contributor is: $ git checkout -b jk/topic origin $ while true; do hack hack hack; commit commit commit; done $ git rebase -i origin which gives me a list of everything on the topic, ready to be reordered, squashed, or edited as appropriate. -Peff