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.
Saw this though for switch/restore:
"THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE."
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.
"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).
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 stash
git pull
git stash pop
# running away to hide myself from the git gods....https://stackoverflow.com/a/30209750
https://leosiddle.com/posts/2020/07/git-config-pull-rebase-a...
See also the reddit thread linked by a nephew comment.
Switch seems straightforward but I don't understand restore. Is it possible to describe restore in terms of checkout?
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)
...
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 -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.
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.
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]
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.
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.
If there is some foolishness, git propagates it EVERYWHERE.
Every git repository is equal. I have no control of proliferation.
Sigh.
If I stapled your HR record, including your bank account and routing number, to our shared refrigerator so I could remember it, would you think that appropriate?
Really, this was the context of our meeting.
Now I am left with the aftermath of his departure, and knives at my sides.
edit: mistakes happen always it is better to change the workflow in such a way that a the consequences can be contained.
The other reply comments are saying the same thing, but your (parent) comment needs to be called out.
If possible, switch from using passwords or tokens without expiry to using ephemeral or time-limited tokens such as machine or pod identities, JWT tokens, IAM service accounts, public/private key pairs (if you can get by with only a public key in the repo) or two-factor authentication. Consider distributing time-limited passwords with Hashicorp Vault.
Some teams might use a cloud-hosted secrets manager or password manager like 1password to distribute passwords and then have code load the password as it runs on a developer machine. GitHub has a secrets scanner, if you pay them enough money for “Advanced Security” such that secrets can never be pushed upstream if recognized as such.
Also, converting from any repo format to another repo format requires care and multiple repeated attempts. A lot can go wrong. Reposurgeon (from a sibling comment) is highly recommended but also not easy to use. It takes a lot of attention to detail to really get the details right.
We had the same problem in TFS.
I found them, I warned them, my riot got us kicked off our shared server.
We migrated to our corporate TFS cloud, and they kicked us off for precisely the same reason.
This just won't/can't stop.
Here’s a brief précis on getting started: https://gist.github.com/ryfactor/f70529438f254d44c0077176508...
It's such a common problem that there's been many tools and workflows that have been set up to mitigate it. This situation often results from not having those tools and workflows in place to give even the "idiots" a "pit of success" to fall into.
e.g., pre-commit hooks installed on dev machines by team policy, and pre-receieve hooks on central repos, both along with CI jobs running truffleHog etc. And even that is downstream of proper code design of minimizing credential use, and focusing/localizing it into files which are already .gitignore'd