From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Worth Subject: Re: Two crazy proposals for changing git's diff commands Date: Thu, 09 Feb 2006 15:44:20 -0800 Message-ID: <87bqxgxfl7.wl%cworth@cworth.org> References: <87slqtcr2f.wl%cworth@cworth.org> <7vfymtl43b.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_Thu_Feb__9_15:44:20_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: git@vger.kernel.org X-From: git-owner@vger.kernel.org Fri Feb 10 00:45:22 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 1F7LTT-00008p-2C for gcvg-git@gmane.org; Fri, 10 Feb 2006 00:45:19 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750839AbWBIXpQ (ORCPT ); Thu, 9 Feb 2006 18:45:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750838AbWBIXpP (ORCPT ); Thu, 9 Feb 2006 18:45:15 -0500 Received: from theworths.org ([217.160.253.102]:30956 "EHLO theworths.org") by vger.kernel.org with ESMTP id S1750839AbWBIXpO (ORCPT ); Thu, 9 Feb 2006 18:45:14 -0500 Received: (qmail 11443 invoked from network); 9 Feb 2006 18:45:13 -0500 Received: from localhost (HELO raht.localdomain) (127.0.0.1) by localhost with SMTP; 9 Feb 2006 18:45:13 -0500 To: Junio C Hamano In-Reply-To: <7vfymtl43b.fsf@assigned-by-dhcp.cox.net> 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_Thu_Feb__9_15:44:20_2006-1 Content-Type: text/plain; charset=US-ASCII On Wed, 08 Feb 2006 17:21:12 -0800, Junio C Hamano wrote: > Carl Worth writes: > > Can anyone else think of common use cases for these various > > operations that I've missed? > > If there is none, then that means we have covered everything. > But a more interesting question to ask is "are there useful > comparisons that the existing diff lowlevel does not give me > with a single command". And the answer is of course yes. Yes, that's a more useful way to ask the question. > For example, you cannot preview "git commit --include paths..." > with a single low-level command. You would need to run > "git-diff-index --cached HEAD" for paths that are _not_ > specified, and "git-diff-index HEAD" output for paths that you > will give to "--include" when you make that commit. Personally, I see that as an argument against adding the --include semantics. It's a single command that is committing a mix of the index and the current files, (which neither "commit" nor "commit -a" do). Granted, Linus has said that he has relied on these existing semantics, (but he also conceded willingness to retrain to "update-index paths; commit" instead). So there's some food for though there. > Of course, learning various flags to give "git diff" is part of > understanding the index, so if the user understands index, "git > diff" without arguments will _not_ be the only diff command the > user uses for a preview. And I suspect that depending on what > development style you would use, the definition of "useful > comparisons" would be different. Yes, and I think it would be nice if the different workflows could be captured by different subsets of commands, (rather than a mishmash of different options to the same commands). For example, I *think* we have consensus that two different, equally reasonable, workflows might currently use the following sets of commands (this is for basic work-preview-commit): Index-lover: update-index diff --cached commit Index-ignorer: diff HEAD commit -a So, what I'm trying to work towards is a situtation where those workflows are captured through obviously-correlated command subsets. This is what I was getting at in the PS. of my previous post. For example, the above could be, (ignoring the clash with existing core commands), something like: Index-lover: update-index diff-index commit-index Index-ignorer: diff-files commit-files [Note that due to the name clash problems, I'm not making a serious proposal here---merely showing again the consistent naming I'm interested in.] The point of an exercise like that is that people could then settle on appropriate workflows by reading a small subset of man pages that link to each other, in their entirety. Compare that with the previous command examples where the workflow is documented in little subsets of man pages scattered about. And please pardon me for my current fixation on the learnability of git, but I am in the situation of "selling" git to my fellow maintainers, (some of whom are saying "mercurial looks easier to learn"). > No, the goal should be for normal workflows there should be *no* > need to use lowlevel commands by end users day-to-day. Sure. In that light, try to conceive as my proposed "diff-files" and "diff-index" commands as two new highlevel commands. They would be useful in day-to-day operation, and most commonly without any need for command-line arguments. Those two operations exist today within the git-diff wrapper already as "diff HEAD" and "diff --cached HEAD" (or "diff --cached). But as described above, I think it would be better to put these operations on separate command names, and get them down to not requiring any command-line arguments in their common usage. > I have not typed lowlevel commands from the command line for > quite a long time, except when I am debugging, and except when I > wanted to see "diff-tree --cc" output for a single commit, only > because there was no suitable wrapper. If you compare my above two chunks of example commands, there's nothing like a low-level vs. high-level distinction between them. It's more about separate command names being uses for different use cases and consistent naming used to group related commands within a use case. > The last reason is now > gone thanks to "git-show" Linus added. So as far as *MY* > workflow is concerned, that goal has already been achieved. I confess that prior to reading the replies from you and Linus I had never heard of git-show. I'll go look at that now, as well as consider the suggestion to extend git-status to give me what I'm looking for. Anyway, thanks for all the patience. I'm really enjoying the conversation, and I hope I'm not being a bore. -Carl --pgp-sign-Multipart_Thu_Feb__9_15:44:20_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBD69PU6JDdNq8qSWgRArg7AJ4w/R3bRqqWiOLOIbJEexxcso1SsACcDQ7b ylXc5bxmjNn31Ql0CcsPkcA= =xLU0 -----END PGP SIGNATURE----- --pgp-sign-Multipart_Thu_Feb__9_15:44:20_2006-1--