From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Worth Subject: Re: Two ideas for improving git's user interface Date: Fri, 03 Feb 2006 16:20:38 -0800 Message-ID: <87lkwsvusp.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> <87lkwupsbr.wl%cworth@cworth.org> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Fri_Feb__3_16:20:32_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 Sat Feb 04 01:21:38 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 1F5BBF-0006ro-22 for gcvg-git@gmane.org; Sat, 04 Feb 2006 01:21:33 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946124AbWBDAVa (ORCPT ); Fri, 3 Feb 2006 19:21:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1946132AbWBDAVa (ORCPT ); Fri, 3 Feb 2006 19:21:30 -0500 Received: from theworths.org ([217.160.253.102]:37301 "EHLO theworths.org") by vger.kernel.org with ESMTP id S1946127AbWBDAVa (ORCPT ); Fri, 3 Feb 2006 19:21:30 -0500 Received: (qmail 20166 invoked from network); 3 Feb 2006 19:21:29 -0500 Received: from localhost (HELO raht.localdomain) (127.0.0.1) by localhost with SMTP; 3 Feb 2006 19:21:29 -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_Fri_Feb__3_16:20:32_2006-1 Content-Type: text/plain; charset=US-ASCII On Wed, 1 Feb 2006 17:23:38 -0800 (PST), Linus Torvalds wrote: > > I tend to have a certain fairly constant set of changes in my working > tree, namely every time a release is getting closer, I always tend to have > the "Makefile" already updated for the new version (but not checked in: I > do that just before I actually tag it, so that the tag will match the > commit that actually changes the version). OK. That use case I understand just fine. > However, if the question was an even stricter "do you ever commit > _changes_ to a particular file where the last HEAD, the index _and_ the > working tree are all different", then the answer is actually "Yes" to that > too. Yes, this is the question I was trying to ask. Thanks for pretending that I had actually asked it, and then answering it as well. > What has happened is that I have had merges that have content conflicts > that I fix up by hand, but exactly _because_ I fix them up by hand, I > actually want to re-compile the kernel and test my fixups. OK. I hadn't anticipated this use case, but I am interested in exploring it more fully. > And in that case, I will actually re-apply my manual Makefile change, even > if that file was part of the merge changes (in which case I had had to > first un-apply the change in order to do the merge). Are the un-apply and re-apply operations here primarily manual? or does git help you much with those (beyond alerting you that the merge cannot take place before you un-apply things)? > The thing is, once you get used to the git "index" as a staging place, > it's really really powerful. I believe that the staging operations you perform are quite desirable, but I wonder if existing primitives in git might not provide a more powerful basis for the kinds of operation you're performing. For example, in the case of the not-quite-ready-to-be-committed changes that you want to carry along, couldn't you get additional benefits if those changes could live on their own branch? I suppose there may be a missing operator needed to allow you to easily merge *and* unmerge that branch if needed. Would that seem at all feasible? If so, could your not-ready changes be implemented as some branch that is automatically unmerged prior to commit and then re-merged afterwards? Or something like that? I guess the feeling I get is that staging into the index feels conceptually similar to a commit to a branch, but it's a uniquely weak branch (only one revision per file). And this uniqueness also introduces complexity (the various diff operations), as well as possibilities of confusion when committing. Meanwhile the response to the commit confusion seems to be to add yet more complexity to commit which doesn't seem like an improvement to me. [I'm maybe too far out on a limb at this point, since you've definitely identified a use case for staging in the index, and all I've offered as an alternative is hand-waving about "branches should be able to do that". But if nothing else, I'm floating some ideas out loud, and next I'll try experimenting more with possibilities for non-index staging.] I'm already having a lot of fun with git. It's a very impressive tool, with a surprisingly simple/powerful core. > Actually, we do exactly that. Right now we expressly limit the "preview" > to just the filenames, but we literally do run > > git-diff-index -M --cached --name-status --diff-filter=MDTCRA HEAD > > as part of "git status", and the eventual end result is what we will > populate the commit message file with for your editing pleasure. Yes, that's a good thing to do. In my personal workflow, a pre-populated commit message is a bit late, since I want to review and convince myself I like things before I type the magic word "commit". And I'm not claiming that a preview patch is impossible to generate, I'm just saying that it's currently rather hard to figure what the correct correspondence for arguments to diff and arguments to commit, (see more on this point in another branch of this thread). -Carl --pgp-sign-Multipart_Fri_Feb__3_16:20:32_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBD4/NW6JDdNq8qSWgRAtcRAKCJxC/+XhW5/ineNiQMiIvhizxCIACggqlO xwp1PkhxiC52CipHyz2i4bk= =2ora -----END PGP SIGNATURE----- --pgp-sign-Multipart_Fri_Feb__3_16:20:32_2006-1--