Avery Pennarun <apenwarr@xxxxxxxxx> writes: > You seem to have forgotten the "git commit" step before switching back > to master. No, I passed over the commit in my example. I know that after the commit the things are as they ought to be, but what if I can't do a commit because I am in the middle of coding and have to have a break? > You have a modified file in your repository; what did you *want* to happen > when you switched branches? I want an unchanged file in master if I switch there (because I worked in a different branch) and a changed version in the test branch. Why is the *master* different depending on whether my work in test in still going on or committed?! Actually, I cannot image how branches are practicable if I always have to have in mind possibly still uncommitted work. Shouldn't it be git's work to ensure that master will remain it was when branching? Without git I'd make a copy for testing new features. With git, it seems that I have to do the same (a clone). This is what I don't understand. > (Many people find the current behaviour very convenient.) I find it highly confusing. I understood a branch as something I can do in whatever I want without affecting master. But now a learn that everything I do in the branch will happen in master, too, until I commit. Strange. Very strange. > You might also want to look at the "git stash" command. Yes, but isn't it annoying to leave the test branch always either with stash or commit in order to have an unchanged master?! Ingo -- 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