Fwd: [BUG] "git checkout BRANCH -- FILE" deletes staged commits

From: Tasnad Kernetzky <tasnadk@gmail.com>
Date: Nov 25, 2019, 20:18 UTC
Message-ID: <b1898690-667b-f413-7ac1-08ef733e7fa5@gmail.com>
In-Reply-To: <aaa2b05a-4c0c-8194-6488-f1b770f3b852@gmail.com>

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: [...]

Show 8 quoted lines

> 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 :)