Hi Brandon, Thanks for your deep inspection! I know that the checkout command I was using was supposed to overwrite the file, but I didn't know that it automatically stages changes. So I agree, that step makes sense and I should have rtfm. My only suggestion for the docs would be to add "staging" or so to the sentence "When a |<tree-ish>| is given, the paths that match the |<pathspec>| are updated both in the index and in the working tree.". However, I think it's also clear enough as-is, so I don't see much room for improvement there. Please find my last comment in-line. Best, Tasnad On 22.11.19 04:14, Brandon McCaig wrote: [...] > When you switch back to branch B the state of the tst file is the > same as it exists in the branch B. There is no conflict here so > it succeeds, and once it does you no longer have any changes made > to tst because the version in your index and working tree matches > the version in the HEAD commit. > > git status at this point would report nothing (assuming no other > files are modified). This is the point I actually considered as a bug. There are staged changes and usually git doesn't let me switch away from a branch in such cases. Although I don't lose data, I do lose the newest state of the master branch, if I'm not cautious and remember that I copied over changed from "B". I would prefere at least a warning :)