On Oct 2, 2007, at 7:53 AM, Junio C Hamano wrote:
* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits + rebase: allow starting from a dirty tree. + stash: implement "stash create" Instead of refusing to rebase, telling you that your work tree is dirty, this stashes your local changes, runs rebase and then unstashes automatically. That _sounds_ nicer and easier to use, but I am not sure if it is a wise/sane thing to do. We may want to revert the "autostash" from rebase. Opinions?
What would happen if 'git stash' fails to work? Could this bring the repo in a state that is hard to recover from? Especially if 'stash' commands were run automatically for you. Maybe if you had a choice you would not choose to use stash but would commit your changes, or would bring your work tree in a clean state by other means. I'm a bit concerned because 'git stash' still doesn't work for me when the work tree is dirty because of a changed subproject (in msysgit with git 1.5.3). After I run 'git stash' the work tree stays dirty. How would "autostash" behave? BTW, I run 'git submodule update' to bring the tree into a clean state and later manually check out the previous head in the submodule. Quite annoying, but not directly related to the discussion above. Steffen - 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
