From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Robert Anderson" Subject: Re: An alternate model for preparing partial commits Date: Sat, 28 Jun 2008 11:25:16 -0700 Message-ID: <9af502e50806281125v5459f7deuc14256044b3e726@mail.gmail.com> References: <-8386235276716376372@unknownmsgid> <9af502e50806271555j3cd06ecau122b11217f612217@mail.gmail.com> <7viqvuo4hq.fsf@gitster.siamese.dyndns.org> <9af502e50806271708p7979ae65k61b71be90efff2c4@mail.gmail.com> <9b3e2dc20806280734i6ca17cc8i447c2e2db67e8051@mail.gmail.com> <9af502e50806280930u788f81e2j77adf147a0e4d135@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Stephen Sinclair" , "Git Mailing List" To: "Jakub Narebski" X-From: git-owner@vger.kernel.org Sat Jun 28 20:26:51 2008 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 1KCf8J-0006mj-OT for gcvg-git-2@gmane.org; Sat, 28 Jun 2008 20:26:48 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753500AbYF1SZW (ORCPT ); Sat, 28 Jun 2008 14:25:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753437AbYF1SZW (ORCPT ); Sat, 28 Jun 2008 14:25:22 -0400 Received: from fg-out-1718.google.com ([72.14.220.154]:35709 "EHLO fg-out-1718.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753295AbYF1SZV (ORCPT ); Sat, 28 Jun 2008 14:25:21 -0400 Received: by fg-out-1718.google.com with SMTP id 19so474699fgg.17 for ; Sat, 28 Jun 2008 11:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=o+QMUcsiz63YHUtg7+Z1v4UfJTnb9KcOkGLp/4qFacU=; b=dIyEHTuMvCKoD+7BaFwEPoojG+ENAK3E1kN6qEwfCaXMnuFeGQuonWRF6YjX6bFnNZ sGzyIR62f3iQkgcQ/DruKmRtfEna8KJMOTYtZJsrwdrtrNv1YjCyzYZ5/jkxlpmnwc04 WljbgkfDyTy9zFmA74vC6zXRkWmeJ0y4LguDQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=MbEN7nW04QIA6uZ4VF3c6/GlLZYAHDYcanaPBuyRIvt6Gaa6suAnBhAU0W0sx0e18A U1YMjN4EaMavHxLg+yuHKw+NVEnpo6excuCgl8oKg0X4yYRC+QXWrNK1Ur3vUPA7VY5a NWfwNCQXQGOY4ajqGdVQoC7A0s1EsRKjLxXdY= Received: by 10.86.49.3 with SMTP id w3mr1066900fgw.68.1214677517059; Sat, 28 Jun 2008 11:25:17 -0700 (PDT) Received: by 10.86.4.6 with HTTP; Sat, 28 Jun 2008 11:25:16 -0700 (PDT) In-Reply-To: Content-Disposition: inline Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Sat, Jun 28, 2008 at 10:12 AM, Jakub Narebski wrote: > "Robert Anderson" writes: > >> On Sat, Jun 28, 2008 at 7:34 AM, Stephen Sinclair wrote: >> > The answer is simple: you should not be making partial commits to a >> > repo that has been cloned. You should instead be working somewhere >> > else and then pushing to it. So this whole sentence is just a moot >> > point itself. >> >> Let me amplify my objection to this. >> >> Who has 100% foresight that what they are doing is going to end up in >> a state where they'd like to make partial commits? To take a quote >> from a blog post, 'Git means never having to say, "you should have"'. >> And mostly it doesn't, and that's big improvement over other systems. >> But, that is what you are saying here. I "should have" realized that >> I should have pulled and fiddled with my changes there, and then >> pushed. >> >> Well, Dmitri and others will now say, why not just always pull and >> work somewhere else? And the reason is that because this creates >> extra, unnecessary steps the vast majority of the time when I do >> create a commit that I like and want to keep as-is in the first try. >> Why should I have to pull, commit, hack, and push, when hack and >> commit is all I need to do the vast majority of the time? It is >> redundant, unnecessary work and complexity that I should not have to >> pay for when I don't need it. > > I think that in most cases the setup looks like the following: there > is private non-bare repository, ehere you can use topic branches, > and change and rewrite those changes at will, be it using plain rebase, > rebase --interactive, or some patch management interface like StGit > or Guilt. That is where you clean up your commits till they all fill > some standards / convention, like compiling (at least), or pass the > testsuite. In my opinion it looks like that because git has poor support for creating good partial commits the first time around. I also think all of this rebase -i style approach is fine for an experienced power user if they like that approach, but that splitting the changes in a working tree is a very basic usage that should be a part of a "Git in 20 minutes" tutorial. StGit, rebase -i, etc., should not. In my experience this is pretty much the *first* thing a developer faces when they decide that having a good incremental change history is a good practice they want to follow. They usually shrug, commit the hairball, and resolve to do better next time. But this is an unavoidable scenario in real world development, and a good SCM manager should have convenient facilities for dealing with it, that don't reach into the power user toolbox like rebase -i (and let's face it, that is an absurdly counterintuitive command for the job at hand), or require auxilliary tools like StGit. The index is a start. But, IMO, it isn't sufficient. Stay tuned for some proposals about improving partial commit support. Thanks, Bob