Markus Elfring <Markus.Elfring@xxxxxx> writes: >> If you are starting from "if your work tree is dirty, you MUST stash >> before checking out another branch", the suggestion is understandable. >> But the thing is, that starting point is not quite correct. > ... > When will it not be needed to reset the work tree to the last corresponding commit? A response to a month old message is a blast from the past ;-). The answer is "almost always" for me. IOW, if checkout stashed away my local changes, it would be very inconvenient. It is important to understand that a local change does not belong to your current branch (it does not belong to _any_ branch). It belongs to you, and you can take it around while switching between branches. And that is a big time-saving feature. This lets you work like this: - You are reading a mailing list message that asks for help, and you know the solution---you can give the help real quick. - You hack in whatever branch that happen to be checked out. The change is perfect, it works. - The branch you happen to have checked out was 'next', but the solution is a bugfix, and should go to 'maint'. Now, at this point, you want to checkout 'maint' without losing your local change. The paths you touched with your quick fix are often not different between the two branches, and "checkout maint" will checkout the branch while keeping your local changes intact. All that is left for you to do is to run another round of test to make sure that your fix didn't depend on anything not in 'maint' and commit the change with appropriate log message, and then you can go back to whatever you were doing with "checkout next". When the change involves paths that were touched between 'maint' and 'next', of course you won't be able to switch without merging the local change to the difference between 'next' and 'maint'. There are a few workflows to deal with such a case, and the easiest is "checkout -m", if you are confident that you can resolve it. In a case where "checkout -m" would result in a conflict too big to resolve, the original fix you made would not be applicable to 'maint' (iow, you should have solved it differently starting from 'maint'), and you may end up doing "reset --hard" and start from scratch, but that is a rare worst case. I said it is rare, because you would notice, while doing the "quick fix" based on 'next' codebase, that the code you are touching have changed since 'maint' and won't be applicable to its final destination (by that time you know you are "fixing"), and you won't waste too much time continuing to work in a checkout of 'next'. -- 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