First of all, I'm long time going git n00b (still mainly p4, and g4 for a bit user), but welcome any hints to easy going with git (have to use it occassionally).
Saw this though for switch/restore:
"THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE."
Hmm, maybe I should leave as-is, for the time being, anyway! Thank you!
Update: based on other comments, I WILL seriously look into replacing the use of checkout. It sounds like these newer features are probably stable enough for the simple things that are being done in the blog post, and that updating the post will more it a bit more useful as a starting point for learning git.
I'm thinking of posting the modern syntax as an alternative rather than a replacement to checkout, but I have yet to investigate how stable things are now... will do when I have time.
But meanwhile, the checkout method is fine, it works, and it's well-established for many years.
Thank you, and that's a good advice from the comment:
"So if you're writing a script that needs to work with dozens of past and future Git versions, use git checkout. If you need to teach humans how to talk to Git, use git switch. Some details of some flags may change in the future, but I'd argue that that'll be a smaller mental challenge than trying to teach which parts of git checkout do what."
I'll try to use more switch/restore
I've actually used "git stash" more than it should be (I'm probably applying real bad "p4/g4/svn" like ideas in my head to the development. As soon as I go into project with few more people, and I'm lost, though I was able to make few PR's in github for things - but everytime had to le-learn the process).
I sometimes use git stash as a safer alternative to git reset --hard HEAD. git stash -> check that the state you've reverted to is actually what you want -> git stash drop. And since internally stash is just creating a commit, it's even possible to recover the changes if they haven't been garbage collected.
I thought so, like I'm not putting much thought behind it of sorts, also it puts into uncomfortable sitatutions sometimes should I merge, or forward something, or who knows what...
Internally Google started on Perforce and gradually replaced its backend. Their client (not available outside their org) is g4 rather than p4.
Some dedicated/stubborn devs also used to (maybe still do?) manage local history in a git-based tool with pushes on demand to a g4 changelist for review.
Git itself seems to recommend these commands e.g. if I do "git status", and there are changed files, git says:
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
...
Another example where it recommends "switch"
git checkout f9b45dd
Note: switching to 'f9b45dd'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
I, personally, learned to use git a couple of years ago, have never learned to use the `checkout` command, and had no need for it. The goal of `switch`/`restore` is to do everything that `checkout` does while being less of a confusing mess.
See also the reddit thread linked by a nephew comment.
One example, when reverting file changes to previous file state from last commit, the following are equivalent:
`git checkout — $FILE` and `git restore $FILE`.
Wow! That's a really hopeful thing to hear. I have been bemoaning git's bafflingly inconsistent interface for years, and checkout is one of the worst. Glad to hear we can finally move on.
Saw this though for switch/restore:
"THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE."