Hi, Shawn O. Pearce wrote: > Personally I wish git-stash wasn't invented the way it is. I would > have rather seen it as macros to do a quick: > > git commit -m wip-index-state > git commit -A -m wip-worktree-state > > and unwind it with essentially: > > git reset --mixed HEAD^ > git reset --soft HEAD^ > > then its a lot less black magic to users, as they can see it in the > DAG, and its more explicitly tied to the branch they were on at the > time they ran the stash. I think its rare you'd stash something > then switch to another branch to apply it. But that could easily > be done with cherry-pick. Just a side note: I, for example, have a stash in which some "valgrind ..." string is prepended to some lines in some test scripts. I apply the stash on different branches and after testing I reset the file (or checkout -f another branch). I never really want to commit these changes. So, the alternative for this use case (if there was no git-stash) is to have a "valgrind" branch somewhere and do some "cherry-pick -n" of those commits, right? Hmm, it seems that this is the better way in the long run. But "git-stash" seemed to be the natural way at first. Regards, Stephan -- Stephan Beyer <s-beyer@xxxxxxx>, PGP 0x6EDDD207FCC5040F -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
