Steffen Prohaska <prohaska@xxxxxx> writes: > 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 also concerned about the possibility of stash/unstash to fail: that means the user has to deal with two kinds of conflicts (rebase can conflict, unstash can also), which can be confusing. But the current behavior can be greatly improved by just making the error message better. Currently, I have this: $ git rebase branch foo.txt: needs update $ _ I'd prefer something like $ git rebase branch cannot rebase: the working tree is not clean. foo.txt: Changed but not updated Commit your changes, or put them appart with "git stash" and retry. $ _ -- Matthieu - 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
