63 ms·

These days it might be better to teach new users about ‘git switch’ and ‘git restore’ (added in Git 2.23, released 2019-08-16) rather than the two overloaded me

These days it might be better to teach new users about ‘git switch’ and ‘git restore’ (added in Git 2.23, released 2019-08-16) rather than the two overloaded meanings of the confusing ‘git checkout’ command. https://git-scm.com/docs/git-switch https://git-scm.com/docs/git-switch https://git-scm.com/docs/git-restore https://git-scm.com/docs/git-restore

garyrob 4y ago
I'll look into that, thanks!
malkia 4y ago
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."
- garyrob 4y ago
  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.
  - NoahKAndrews 4y ago
    I think this Reddit comment has the right idea, especially now that those commands have been released for 3 years: https://www.reddit.com/r/git/comments/ifkbfz/comment/g2on6yo/ https://www.reddit.com/r/git/comments/ifkbfz/comment/g2on6yo...
    - malkia 4y ago
      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).
      - noSyncCloud 4y ago
        Only used Git and SVN before, sorry for noob question. I guess p4 is Perforce, but what is g4?
        erik_seaberg 4y ago
        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.
        noSyncCloud 4y ago
        Ahh awesome, ok, thanks so much for the lesson. Something to read more about. Cheers.
        malkia 4y ago
        git5 or something - is this still supported? g4 was awesome (still miss it, now just on perforce...)
        erik_seaberg 4y ago
- ilyagr 4y ago
  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.
  - marssaxman 4y ago
    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.
  - dreamcompiler 4y ago
    Funny. I know 'checkout' pretty well but I've never seen 'switch'/'restore' before today. Switch seems straightforward but I don't understand restore. Is it possible to describe restore in terms of checkout?
    - brianzelip 4y ago
      One example, when reverting file changes to previous file state from last commit, the following are equivalent: `git checkout — $FILE` and `git restore $FILE`.
      - computerfriend 4y ago
        Wow, time to get rid of my `git reset-file` alias.
- arunix 4y ago
  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 -
chasil 4y ago
My developers use CVS. Sometimes, they are really stupid, and they will checkin passwords. With the RCS archives, I can use vi (or nano, or any other reasonable editor), and remove this foolishness. When I run "git cvsconvert" any foolishness is ENGRAVED IN STONE. Removal is possible in git, but not easy. This is my problem. THERE ARE SO MANY IDIOTS. What can I do? EDIT: For Windows-centric users of git, you need to run this in every and all repositories RIGHT NOW. git grep -i password $(git rev-list --all) [actually, everybody should try it]
- AnonCoward42 4y ago
  I might be an idiot myself, but would `git rebase -i <commitBeforeSnafu>` do the trick? edit: This is interactive rebase, where you can rewrite history. Instructions are in the file you are editing once the command is executed. As a rule of thumb, don't rebase on production, however with such a SNAFU you probably need to.
  - gizmo686 4y ago
    No. The old commits still exist, a rebase just makes it so that they are not part of the history of the current branch. If you know the commit hash of a commit containing the offending data, you can still check it out. You can also find such commits in the reflog, or if they are part of the history of any other branch or tag. The data is also in git's internal data structures if you know enough to interpret those directly. Still, a rebase is a critical part of fixing this. If you rebase every branch that has the offending data in their history, and recreate any tags that have the data, then the offending data would be present only in unreachable objects (which can still be found through the reflog or knowing a commit hash). Eventually, git's garbage collection will clean up such unreachable data. You can force this behaviour earlier by using the `git gc` command. By default git will not remove recent objects (which is why you can reflog your way out of a botched rebase), but you can override this behaviour as well. Of course, all of the above assumes you are working on your own repository. Given git's decentralized design, you need to clean up and garbage collect on every clone that did a fetch since the offending data was checked it. Worse, each clone also keeps track of remote branches, and considers those to be reachable as well, so a garbage collection will not work correctly until a given clone fetches from all of its remotes after those remotes removed the offending data [0]. Further, there is not good tooling to check that you actually did this correctly, so when you are done, you need to hope you fully purged the data. The plus side of all of this is that once something is checked in, it is extremely difficult to accidently delete it. The downside is that it is also difficult to deliberately delete it. Also, it is fairly easy to make it difficult enough to find to negate the day to day benifets of it still existing, which does very little to protect against a motivated attacker. [0] Fourtuantly, you do not need all of the remote to have garbage collected, so you could have every make the data unreachable, fetch on all remotes, then garbage collect.
ajross 4y ago
My feeling is that new users shouldn't be taught about branches in their local repo at all. Typical cloud-based git{hub,lab}/gerrit/etc.. workflows generally store all branches worth talking about on remote systems anyway. I find I don't ever bother with managing local branches for anything in my own workflows. I just git-reset --hard to bounce between fetched copies of upstream branches as needed. Stuff I need to work on for more than a few commits in an afternoon gets pushed to a remote branch regularly anyway as part of general safe development hygiene.
garyrob 4y ago
I'm going to think about this more. Ironically, I'm in a situation for a few days where I can't really focus on technology. It sounds like switch and/or restore are probably stable enough that they could be used instead of checkout for the specific tasks I'm trying to do in the blog post, so yet another update will be warranted when I get a chance! It's completely usable as-is, so I hope no one is scared off by thinking it should incorporate switch and/or restore. It's usable now, and if you do feel like saving a link to it for future reference, I expect that there will be another way in the future to do a couple of the tasks using the more modern syntax.
wizofaus 4y ago
I only found out about git switch recently - super handy when you want to checkout another dev's branch that isn't tracked locally yet. There's a case to be made for reserving 'checkout' for when you specify a filespec rather than a branch.
fud101 4y ago
is there a good guide on these two in the vein of the OP?
lttlrck 4y ago
FYI they are covered in "man giteveryday" which is mentioned in the second paragraph of "man git"

garyrob 4y ago

I'll look into that, thanks!

malkia 4y ago

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

garyrob 4y ago
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.
- NoahKAndrews 4y ago
  I think this Reddit comment has the right idea, especially now that those commands have been released for 3 years: https://www.reddit.com/r/git/comments/ifkbfz/comment/g2on6yo/ https://www.reddit.com/r/git/comments/ifkbfz/comment/g2on6yo...
  - malkia 4y ago
    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).
    - noSyncCloud 4y ago
      Only used Git and SVN before, sorry for noob question. I guess p4 is Perforce, but what is g4?
      - erik_seaberg 4y ago
        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.
        noSyncCloud 4y ago
        Ahh awesome, ok, thanks so much for the lesson. Something to read more about. Cheers.
        malkia 4y ago
        git5 or something - is this still supported? g4 was awesome (still miss it, now just on perforce...)
        erik_seaberg 4y ago
ilyagr 4y ago
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.
- marssaxman 4y ago
  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.
- dreamcompiler 4y ago
  Funny. I know 'checkout' pretty well but I've never seen 'switch'/'restore' before today. Switch seems straightforward but I don't understand restore. Is it possible to describe restore in terms of checkout?
  - brianzelip 4y ago
    One example, when reverting file changes to previous file state from last commit, the following are equivalent: `git checkout — $FILE` and `git restore $FILE`.
    - computerfriend 4y ago
      Wow, time to get rid of my `git reset-file` alias.
arunix 4y ago
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 -

chasil 4y ago

My developers use CVS. Sometimes, they are really stupid, and they will checkin passwords. With the RCS archives, I can use vi (or nano, or any other reasonable editor), and remove this foolishness. When I run "git cvsconvert" any foolishness is ENGRAVED IN STONE. Removal is possible in git, but not easy. This is my problem. THERE ARE SO MANY IDIOTS. What can I do? EDIT: For Windows-centric users of git, you need to run this in every and all repositories RIGHT NOW. git grep -i password $(git rev-list --all) [actually, everybody should try it]

AnonCoward42 4y ago
I might be an idiot myself, but would `git rebase -i <commitBeforeSnafu>` do the trick? edit: This is interactive rebase, where you can rewrite history. Instructions are in the file you are editing once the command is executed. As a rule of thumb, don't rebase on production, however with such a SNAFU you probably need to.
- gizmo686 4y ago
  No. The old commits still exist, a rebase just makes it so that they are not part of the history of the current branch. If you know the commit hash of a commit containing the offending data, you can still check it out. You can also find such commits in the reflog, or if they are part of the history of any other branch or tag. The data is also in git's internal data structures if you know enough to interpret those directly. Still, a rebase is a critical part of fixing this. If you rebase every branch that has the offending data in their history, and recreate any tags that have the data, then the offending data would be present only in unreachable objects (which can still be found through the reflog or knowing a commit hash). Eventually, git's garbage collection will clean up such unreachable data. You can force this behaviour earlier by using the `git gc` command. By default git will not remove recent objects (which is why you can reflog your way out of a botched rebase), but you can override this behaviour as well. Of course, all of the above assumes you are working on your own repository. Given git's decentralized design, you need to clean up and garbage collect on every clone that did a fetch since the offending data was checked it. Worse, each clone also keeps track of remote branches, and considers those to be reachable as well, so a garbage collection will not work correctly until a given clone fetches from all of its remotes after those remotes removed the offending data [0]. Further, there is not good tooling to check that you actually did this correctly, so when you are done, you need to hope you fully purged the data. The plus side of all of this is that once something is checked in, it is extremely difficult to accidently delete it. The downside is that it is also difficult to deliberately delete it. Also, it is fairly easy to make it difficult enough to find to negate the day to day benifets of it still existing, which does very little to protect against a motivated attacker. [0] Fourtuantly, you do not need all of the remote to have garbage collected, so you could have every make the data unreachable, fetch on all remotes, then garbage collect.

ajross 4y ago

My feeling is that new users shouldn't be taught about branches in their local repo at all. Typical cloud-based git{hub,lab}/gerrit/etc.. workflows generally store all branches worth talking about on remote systems anyway. I find I don't ever bother with managing local branches for anything in my own workflows. I just git-reset --hard to bounce between fetched copies of upstream branches as needed. Stuff I need to work on for more than a few commits in an afternoon gets pushed to a remote branch regularly anyway as part of general safe development hygiene.

garyrob 4y ago

I'm going to think about this more. Ironically, I'm in a situation for a few days where I can't really focus on technology. It sounds like switch and/or restore are probably stable enough that they could be used instead of checkout for the specific tasks I'm trying to do in the blog post, so yet another update will be warranted when I get a chance! It's completely usable as-is, so I hope no one is scared off by thinking it should incorporate switch and/or restore. It's usable now, and if you do feel like saving a link to it for future reference, I expect that there will be another way in the future to do a couple of the tasks using the more modern syntax.

wizofaus 4y ago

I only found out about git switch recently - super handy when you want to checkout another dev's branch that isn't tracked locally yet. There's a case to be made for reserving 'checkout' for when you specify a filespec rather than a branch.

fud101 4y ago

is there a good guide on these two in the vein of the OP?

lttlrck 4y ago

FYI they are covered in "man giteveryday" which is mentioned in the second paragraph of "man git"