> 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. It seems that we have got different expectations on the editing work flow when we discuss the following situation. elfring@Sonne:~/Projekte> git --version && mkdir try && cd try && git init --quiet \ > && echo one > XYZ.h && git add . && git commit --message=check-in --quiet \ > && git checkout --quiet -b feature1 && echo two > XYZ.h \ > && git checkout --quiet master && git status git version 1.7.0 # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: XYZ.h # no changes added to commit (use "git add" and/or "git commit -a") I would prefer to return to the unchanged work tree because I made an adjustment for a source file with the intention that this update should only belong to the new topic branch. The switch did not provide a clean state from my view. > - 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. I would create another topic branch before. > - 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. I can follow your view on convenience if the desired software maintenance is so easy as in this example. I guess that it matters if only a simple branch switch is needed or a corresponding content restore will also be required. > 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 would like to be more careful so that I do not want to mix changes by accident. > 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'. I imagine that stashing will help to split the collected changes for different branch targets. Regards, Markus -- 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