6 ms·
> if you do 'git checkout [path]' The entire point of that command is to discard local changes. There is some risk of getting the different forms of checkout
by nemetroid 4y ago
> if you do 'git checkout [path]'
The entire point of that command is to discard local changes.
There is some risk of getting the different forms of checkout mixed up, though, so prefer using switch and restore instead. As far as I know, the only use case of checkout not covered by other commands is checking out a commit that doesn’t have a branch attached to it.
- lisper 4y ago> The entire point of that command is to discard local changes. I think that's arguable, but it's neither here nor there. Someone who is not well versed in git arcana will be surprised that the level of risk associated with 'git checkout [branch]' is radically different from 'git checkout [directory]'. I think a lot of people will learn this the hard way, especially if they have been told "It is very hard to permanently lose work." It's not true. Permanently losing work is as easy as being careless with git checkout.
- wizofaus 4y agoI haven't learned the hard way thankfully, but I certainly found it very surprising. It's not at all obvious, and the GUIs with git support call it something like "Undo changes" or "Revert" etc.
- nemetroid 4y ago> Someone who is not well versed in git arcana will be surprised that the level of risk associated with 'git checkout [branch]' is radically different from 'git checkout [directory]'. I disagree that it's a difference in the level of risk. There's no "risk" that git checkout [path] will discard your uncommitted changes, it's a promise and a certainty. That said, I agree that the breadth of largely unrelated functionality smushed into git checkout is surprising, but it's also one of the few things about Git's user interface that actually has been addressed by new subcommands.