From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Worth Subject: Re: The git newbie experience Date: Mon, 15 May 2006 13:42:47 -0700 Message-ID: <877j4nvx2w.wl%cworth@cworth.org> References: <446778B8.7080201@inoi.fi> <7vfyjcntro.fsf@assigned-by-dhcp.cox.net> <44680C54.8040206@inoi.fi> <7vy7x3x3ux.fsf@assigned-by-dhcp.cox.net> <20060515053133.GB28068@spearce.org> <7v1wuvvg0j.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_Mon_May_15_13:42:47_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: Shawn Pearce , Tommi Virtanen , git@vger.kernel.org X-From: git-owner@vger.kernel.org Mon May 15 22:47:03 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 1Ffjxq-0008SL-Pt for gcvg-git@gmane.org; Mon, 15 May 2006 22:46:51 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751635AbWEOUqj (ORCPT ); Mon, 15 May 2006 16:46:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751629AbWEOUqj (ORCPT ); Mon, 15 May 2006 16:46:39 -0400 Received: from theworths.org ([217.160.253.102]:49324 "EHLO theworths.org") by vger.kernel.org with ESMTP id S1751508AbWEOUqi (ORCPT ); Mon, 15 May 2006 16:46:38 -0400 Received: (qmail 13222 invoked from network); 15 May 2006 16:46:36 -0400 Received: from localhost (HELO raht.cworth.org) (127.0.0.1) by localhost with SMTP; 15 May 2006 16:46:36 -0400 To: Junio C Hamano In-Reply-To: <7v1wuvvg0j.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_Mon_May_15_13:42:47_2006-1 Content-Type: text/plain; charset=US-ASCII On Mon, 15 May 2006 01:39:08 -0700, Junio C Hamano wrote: > - Jack stashes away what he has been working on and cleans up > his mess. > > git checkout -b stash ;# risks error when "stash" exists > git commit -a -m 'Stashing WIP' > git checkout master ;# assuming that was where he was I really like the proposal made elsewhere to implement a new: commit -b which would then allow for a single command to achieve at least the first two commands above: git commit -a -b stash -m 'Stashing WIP' It might even make sense for this command to effectively perform all three of the above commands. That is, should "commit -b" also checkout the newly created branch or should it leave HEAD unchanged. I'm not sure. > You have to teach the new user to (1) name something, only to > immediately discard it when he returns to what he was in the > middle of, (2) remember to clean up the temporary thing once he > is done lest he forgets to clean it up (and common names like > "stash", "tmp" will be reused by accident causing grief next > time he needs to do another stash), and (3) use of --no-commit > pull. I threw out a simple git-stash earlier, (which stashed to a branch rather than to a file). I've spent some time using it, and am now quite sure it's the wrong thing, and the above problems outline the defect quite well: 1) Naming. Here, git-stash is doing too much. I prefer the idea of a stash command using a branch rather than a patch file, (and allowing one stash per branch rather than one stash per repository). But the namespace of branches is something the user owns, and we should avoid adding commands that steal from it unnecessarily. So my git-stash fails on this point, while "commit -b " is much better. 2) Cleanup and --no-commit pull Here, git-stash is doing too little. It's really only performing one piece of what needs to be done in order to switch back and forth between different topics of work. So here are my thoughts on what I'd like instead: In git, a branch is what we use to name a topic of work. Historically, a branch has been extremely lightweight, (a name and reference to a parent for subsequent commits). But there's been a recent trend (in proposals at least) to add other, useful things to a branch, (as in the discussions of branch-specific configuration). In my work, I've found that the uncommitted state of my working tree is something that I associate very strongly with my "current topic" and expect the branch-changing commands respected that. In particular, when using checkout to change branches, unless I've specifically stated with "-m" that I want to carry my changes along, I would like git to stash my working tree "into" the branch I'm switching away from. Similarly, when switching to a branch, I'd like to have the working tree restored to what it was the last time I switched away from that branch. Does that seem unreasonable to anyone? The only snag I've imagined is that when using "checkout -m" to switch to a branch that also had a stashed working tree, then there's a merge to be performed and that could obviously conflict. I've intentionally not mentioned how the stashing/restoring should be implemented, since the user shouldn't care. But a merge conflict is one case where the implementation might leak out to the user. The wimpy thing to do would be to refuse to allow "checkout -m" to a branch with stashed changes. -Carl --pgp-sign-Multipart_Mon_May_15_13:42:47_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEaOfH6JDdNq8qSWgRAoWSAKCFYF3oHOQdZ0NfX1Jn9cdbyTNIVwCghA8P YYyY8gyUpCI9oMJSByMwN1M= =5wl0 -----END PGP SIGNATURE----- --pgp-sign-Multipart_Mon_May_15_13:42:47_2006-1--