From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Worth Subject: Two ideas for improving git's user interface Date: Wed, 01 Feb 2006 15:33:44 -0800 Message-ID: <87lkwupsbr.wl%cworth@cworth.org> References: <46a038f90601251810m1086d353ne8c7147edee4962a@mail.gmail.com> <46a038f90601272133o53438987ka6b97c21d0cdf921@mail.gmail.com> <1138446030.9919.112.camel@evo.keithp.com> <7vzmlgt5zt.fsf@assigned-by-dhcp.cox.net> <20060130185822.GA24487@hpsvcnb.fc.hp.com> <7vek2oot7z.fsf@assigned-by-dhcp.cox.net> <7v4q3jlgw2.fsf@assigned-by-dhcp.cox.net> <7vhd7ibza2.fsf@assigned-by-dhcp.cox.net> <7v8xsu91vf.fsf@assigned-by-dhcp.cox.net> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Wed_Feb__1_15:33:38_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: Junio C Hamano , Nicolas Pitre , git@vger.kernel.org X-From: git-owner@vger.kernel.org Thu Feb 02 00:34:49 2006 Return-path: Envelope-to: gcvg-git@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F4RUm-00073J-3S for gcvg-git@gmane.org; Thu, 02 Feb 2006 00:34:40 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423030AbWBAXeh (ORCPT ); Wed, 1 Feb 2006 18:34:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1423031AbWBAXeh (ORCPT ); Wed, 1 Feb 2006 18:34:37 -0500 Received: from theworths.org ([217.160.253.102]:48575 "EHLO theworths.org") by vger.kernel.org with ESMTP id S1423030AbWBAXeg (ORCPT ); Wed, 1 Feb 2006 18:34:36 -0500 Received: (qmail 32205 invoked from network); 1 Feb 2006 18:34:35 -0500 Received: from localhost (HELO raht.localdomain) (127.0.0.1) by localhost with SMTP; 1 Feb 2006 18:34:35 -0500 To: Linus Torvalds In-Reply-To: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.4 Mule/5.0 (SAKAKI) Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: --pgp-sign-Multipart_Wed_Feb__1_15:33:38_2006-1 Content-Type: text/plain; charset=US-ASCII On Wed, 1 Feb 2006 14:35:33 -0800 (PST), Linus Torvalds wrote: > > Agreed. However, I think that one is pretty easy to explain, and > conceptually it's not a problem to just tell people to use the "-a" flag > if they want to get CVS/SVN semantics. "Just use -a" is tempting, but I don't think it's a satisfying stance to take. Consider the following operations: echo "original" > A; git add A; echo "modified" > A; git commit -a -m "add A"; echo "original" > B; git add B; echo "modified" > B; git commit -m "add B" B; echo "original" > C; git add C; echo "modified" > C; git commit -m "add C"; After which we can see: $ git diff diff --git a/C b/C index 4b48dee..2e09960 100644 --- a/C +++ b/C @@ -1 +1 @@ -original +modified To explain this, "just use -a" isn't enough, it would have to be something like, "always use -a or else 'git commit' just won't work and you can end up committing stale garbage". And perhaps "unless you also add the filename to the commit line, then it will start working again." There's explanation for the above behavior requires a rather careful description of the index, the operations, the flags, and some rather subtle interactions between them. I don't even think "embrace the index" is enough to make the above behavior obvious---the variations in the above behavior are a bit too subtle. But I don't think git is doomed to be hard to learn or that its behavior needs to be hard to predict. I think this should be fairly easy to fix. Here's a fundamental question I have, (and thanks to Keith Packard for helping me to phrase it): Is it ever useful (reasonable, desirable) to commit file contents that differ from the contents of the working directory? I don't think it is, (but please let me know if I've missed some useful case). Idea #1 (prevent the index from being used to commit stale data) ------- If this isn't useful, then I think git would do well to make it harder/impossible to perform this operation. For example, the index could have a new notion of "use working directory contents" for a given file in addition to the current "use this blob". This would allow a user to use the index to stage subsequent file additions/modifications for commit without introducing the various opportunities for confusing commits of stale data. I would think this would then naturally resolve the confusion around the various diff operations, (diff-index, diff-index --cached, and diff-files). Idea #2 (make it easy to preview diffs of what will be committed) ------- Independent of the above, I'd like to propose another change to help prevent confusion and to help users learn git. There should be an obvious "diff" operation that presents exactly the result of what any "commit" operation will perform. I assume that there currently exist appropriate diff operations for any commit, but the correspondence certainly isn't obvious. For example, the simplest of commit commands: git commit seems to correspond to a rather complex diff command (which I may not have completely correct yet---and if not, that would just demonstrate the point even more): git diff-index -p --cached HEAD What I would love to have is the ability to pass the same arguments to git diff to get a preview of what any get commit would do. For example, something like: git diff # would be a preview of: git commit git diff -a # would be a preview of: git commit -a git diff fileA fileB # would be a preview of: git commit fileA fileB etc. Again, thanks for your consideration to these thoughts from woefully clueless and inexperienced user. -Carl --pgp-sign-Multipart_Wed_Feb__1_15:33:38_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBD4UVY6JDdNq8qSWgRAsY4AJ9ETp2hP2f0L4I9YU8fJf1oj66ptgCghMam XRA/AGvoI94xaviuLUTj9nE= =uenq -----END PGP SIGNATURE----- --pgp-sign-Multipart_Wed_Feb__1_15:33:38_2006-1--