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 <newbranch> 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 <newbranch>" 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
Attachment:
pgpAKBXNfA0Mj.pgp
Description: PGP signature