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

Tasnad Kernetzky· Nov 25, 2019, 20:18 UTC · lore

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

Brandon McCaig· Nov 26, 2019, 22:07 UTC · lore

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

Tasnad:

On Mon, Nov 25, 2019 at 09:15:18PM +0100, Tasnad Kernetzky wrote:

> Hi Brandon,

Hello,

Show 13 quoted lines

> 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.

I think that Git normally will let you change branches even if you have changes in your index or working tree as long as the version of the file in your destination branch matches the HEAD version. In other words no merge is necessary and no changes can be lost. I regularly do this when I start making changes on develop or master, and then decide to branch after the fact. It's a bit less typing than stashing in between. :)

For example:

	git init checkout
	cd checkout
	echo master >log
	git add log
	git commit -m master
	git checkout -b B
	echo B >>log
	git add log
	git checkout master
	git status

Regards,

-- 
Brandon McCaig <bamccaig@gmail.com> <bambams@castopulence.org>
Castopulence Software <https://www.castopulence.org/>
Blog <http://www.bambams.ca/>
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'