On Tue, Nov 9, 2010 at 2:49 AM, Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: > Casey McGinty <casey.mcginty@xxxxxxxxx> writes: > >> Is there any feature in git to perform and auto stash apply/pop when >> trying to do a merge/rebase in a dirty working dir? This would save >> some keystrokes from time-to-time, and make it easier for new users >> unfamiliar with git. > > I agree with the keystrokes part, but not with the fact that it would > make it easier in general. In the sequence > > git stash > git merge > git stash pop > > conflicts can occur in 2 distinct places. [...] Correct me if I'm wrong, but I think git will only stop you from performing a merge if it would involve touching any of your dirty files, so in the case of merge, I agree with Matthieu that temporarily stashing your changes would probably just increase the risk of confusing the user. However, in the case of rebase, git will not let you rebase if *any* file is dirty. So, in this case of rebase, there are often cases where git prevents a rebase that could have been a stash + rebase + stash pop without any conflicts in the pop step. I know that the fact that 'git rebase' (usually in the form of a 'git pull' configured for rebase on the current branch) forces the user to temporarily stash his changes has been somewhat annoying to some of my colleagues. I actually implemented support for stashing changes using 'stash create' and 'stash apply', but only for non-interactive rebase. The implentation supports a '--stash' argument and a 'rebase.stash' configuration. I am currently working on refactoring git-rebase.sh and git-rebase--interactive.sh, but once that's done, I will post an updated version of the 'git rebase --stash' patch(es). I later found out that this seems to have been attempted at least twice before. The first time by Junio in 6c9ad16 (rebase: allow starting from a dirty tree., 2007-07-09). This was later reverted. I think it was reverted because the stashing was not optional. Some months later, Simon Sasburg sent some patches on the same subject, see http://thread.gmane.org/gmane.comp.version-control.git/63007/. These patches don't see to have been accepted, but I'm not sure why. -- 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