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-show --stat on first commit Date: Tue, 21 Nov 2006 10:39:46 -0800 Message-ID: <87lkm4y77x.wl%cworth@cworth.org> References: <200611211341.48862.andyparkins@gmail.com> <8aa486160611210609h1c2d229ekf0b5e8aeb4f21f11@mail.gmail.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Tue_Nov_21_10:39:40_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit NNTP-Posting-Date: Tue, 21 Nov 2006 18:41:05 +0000 (UTC) Cc: Peter Baumann , git@vger.kernel.org Return-path: Envelope-to: gcvg-git@gmane.org In-Reply-To: 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 1GmaXr-0002zl-3I for gcvg-git@gmane.org; Tue, 21 Nov 2006 19:40:35 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031289AbWKUSkb (ORCPT ); Tue, 21 Nov 2006 13:40:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1031292AbWKUSkb (ORCPT ); Tue, 21 Nov 2006 13:40:31 -0500 Received: from theworths.org ([217.160.253.102]:57486 "EHLO theworths.org") by vger.kernel.org with ESMTP id S1031289AbWKUSka (ORCPT ); Tue, 21 Nov 2006 13:40:30 -0500 Received: (qmail 15854 invoked from network); 21 Nov 2006 13:40:25 -0500 Received: from localhost (HELO raht.cworth.org) (127.0.0.1) by localhost with SMTP; 21 Nov 2006 13:40:25 -0500 To: Linus Torvalds Sender: git-owner@vger.kernel.org --pgp-sign-Multipart_Tue_Nov_21_10:39:40_2006-1 Content-Type: text/plain; charset=US-ASCII On Tue, 21 Nov 2006 08:31:30 -0800 (PST), Linus Torvalds wrote: > I suspect we should make the thing a config option, and default it to > "on". Agreed. That would be fabulous! > That's really the reason why git defaults to not showing the root diff at > all: exactly because for the kernel, the initial commit was state that > "just came to be", and I found it both illogical and annoying to see it as > a diff, since that commit really was a "black hole" where previous history > just disappeared. Ah, that's a rationale I wouldn't have guessed. > There's also another reason for the root being special, which is purely > git-internal: the root really has no parents at all, and the normal "git > diff" is "diff against parents". This is the rationale I was guessing was the cause. It clearly takes a special case in the code to show the root diff, and --root seemed like that special-case implementation leaking into the interface, (where, usually, the user wouldn't expect the first commit to be any different than any other). This looks like yet another case where a feature was added, and a new command-line option with it, when what was really wanted was a new default. > git didn't end up doing that (and I'm personally pretty happy about it), It seems a reasonable enough decision, but it does have some impacts. Several of the tools don't work in the strange state between git-init and the first git-commit. Some of these are getting worked out now, (such as pull), but Junio was still objecting to fixing diff to work. There's a decision to have git's internals support this intermediate state, but all the tools should be made completely functional. This is an important things to get right, since this is the first state in which a new user will have her repository, (right after doing git-init-db as the first step in the tutorial). So it's important to make this state functional and not have to explain the "strange" implementation details "Normally, you would have a branch HEAD at this point, so these commands would usually work even though they don't yet, etc. etc." > So having a config option would solve the problem, If the default is fixed, yes. > but what annoys me > right now about the config options is that we really should have a > graphical front-end to setting those things or something, because while > _I_ don't have any issues with editing a ".git/config" file, I think we're > getting to the point where a lot of our problems are really about "you can > do it, but you have to know a lot about git to even know you can do it". I agree with that statement. But I also think that for the "new user problems" a new graphical tool for twiddling git options wouldn't make the system any less imposing. On the other hand, getting the defaults to be less surprising would definitely help, (and configuration options can be used to good effect to allow "old-timers" to maintain the behavior they're used to as defaults change). -Carl --pgp-sign-Multipart_Tue_Nov_21_10:39:40_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFY0fy6JDdNq8qSWgRAv/JAJ94LkB207MSy8IXTwcKe+EpEzevSQCgjIoZ yWSKLTQXO0776msHRE1UWA4= =Bybr -----END PGP SIGNATURE-----