From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.176.0/21 X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 From: Carl Worth Subject: Re: git and bzr Date: Wed, 29 Nov 2006 23:17:38 -0800 Message-ID: <87slg1tncd.wl%cworth@cworth.org> References: <45357CC3.4040507@utoronto.ca> <20061026101038.GA13310@coredump.intra.peff.net> <877iyne4dm.fsf@alplog.fr> <456B7C6A.80104@webdrake.net> <845b6e870611280410j58bdcd99nc05d0f67489293e4@mail.gmail.com> <456C7592.6020700@ableton.com> <456C9DFF.1040407@onlinehome.de> <456CA981.4010808@onlinehome.de> <456CB197.2030201@onlinehome.de> <456DD76C.4010902@gmx.net> <87bqmpvlxf.wl%cworth@cworth.org> <456E8147.9070304@gmx.net> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Wed_Nov_29_23:17:38_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit NNTP-Posting-Date: Thu, 30 Nov 2006 07:18:32 +0000 (UTC) Cc: git@vger.kernel.org Return-path: Envelope-to: gcvg-git@gmane.org In-Reply-To: <456E8147.9070304@gmx.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.4 Mule/5.0 (SAKAKI) Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: Received: from vger.kernel.org ([209.132.176.167]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GpgBc-0001cp-0p for gcvg-git@gmane.org; Thu, 30 Nov 2006 08:18:24 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758515AbWK3HSV (ORCPT ); Thu, 30 Nov 2006 02:18:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758516AbWK3HSU (ORCPT ); Thu, 30 Nov 2006 02:18:20 -0500 Received: from mx1.redhat.com ([66.187.233.31]:41421 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S1758515AbWK3HSU (ORCPT ); Thu, 30 Nov 2006 02:18:20 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kAU7IIAZ008774; Thu, 30 Nov 2006 02:18:18 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kAU7IIrI000942; Thu, 30 Nov 2006 02:18:18 -0500 Received: from raht.cworth.org (sebastian-int.corp.redhat.com [172.16.52.221]) by mail.boston.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kAU7IGRx003221; Thu, 30 Nov 2006 02:18:17 -0500 To: Raimund Bauer Sender: git-owner@vger.kernel.org --pgp-sign-Multipart_Wed_Nov_29_23:17:38_2006-1 Content-Type: text/plain; charset=US-ASCII On Thu, 30 Nov 2006 07:59:19 +0100, Raimund Bauer wrote: > * Carl Worth wrote, On 30.11.2006 01:05: > > Let's help people do exactly that by making the behavior of "git > > commit -a" be the default for "git commit". > > > Maybe we could do that _only_ if the index matches HEAD, and otherwise > keep current behavior? > So people who don't care about the index won't get tripped up, and when > you do have a dirty index, you get told about it? I thought of that tonight and almost suggested it myself. It would be an attempt to satisfy both "sides" of the debate without either side having to fight with a default they didn't like or configure it away. I did wonder if the powers that be would find it a bit too magic, (the problem with magic things is that they can sometimes be quite confusing when they don't do exactly what you want). But this might just work. It wouldn't be too bad to document, (we already have several commands that change slightly if the index doesn't match, (often by just refusing to do anything in a dirty tree)). And, significantly this would allow for documenting the simple sequence of: # edit file git commit in the tutorial while also allowing what Junio wanted: git update-index file git commit with the behavior of, ("I already said I wanted to do a staged commit when I explicitly updated the index, so don't make me say anything special again when I go to commit"). Can we really get the best of both worlds here? -Carl --pgp-sign-Multipart_Wed_Nov_29_23:17:38_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFboWS6JDdNq8qSWgRAkb6AJ4gSV6KRGKBVi/kMFQO84Z9Js8J3wCfY4ut SV6UEskQ+Nuj/lEhbA3UzBg= =n5lZ -----END PGP SIGNATURE-----