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

[Tasnad Kernetzky <tasnadk@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:
[...]
> 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 :)