One of my favorite ones is git stash, but it's not used here.
Oh Shit, Git
121–130 of 237 posts
Re: Oh Shit, Git
#122Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.
Honestly, when I think of software that I suffered using recently, then UX/UI people are usually the reason, not the solution for that suffering.
Re: Oh Shit, Git
#123Earlier quoted context omitted.
"git bisect --first-parent" gives most of the same benefits for teams that don't rebase/squash. At least until someone does a foxtrot merge and then it never works again
What's a foxtrot merge?
I had to look it up as well. https://blog.developer.atlassian.com/stop-foxtrots-now/
Re: Oh Shit, Git
#124> [git reflog … git reset…] You can use this to get back stuff you accidentally deleted
Pro tip - this is true for commits, but not for accidentally dropped stashes. This is why it’s better to commit first, branching if necessary, than to stash.
“If you mistakenly drop or clear stash entries, they cannot be recovered through the normal safety mechanisms. However, you can try the following incantation to get a list of stash entries that are still in your repository, but not reachable any more [git fsck…]”
https://git-scm.com/docs/git-stash
> Oh Shit! I accidentally committed to the wrong branch! [git reset … git stash …] A lot of people have suggested using cherry-pick for this situation too
Because of the above warning about stash, cherry-pick is indeed a bit safer and more easily recoverable if something goes wrong when moving to the other branch. This particular situation isn’t dire given the premise that you already committed, so the reflog can be used. The situation where it’s more important is if you’re sitting in the wrong branch, have uncommitted work, and git won’t let you switch branches first. In that case, committing first into the wrong branch is recommended over stashing and switching branches, even though it’s slightly more work. I’ve actually watched people mess this up and then get frustrated with the magic incantation fsck stuff and give up and spazz and nuke their repo instead, while shouting “wait! no no no no…” over their shoulder.
Stash is convenient sometimes, but never necessary, always less safe, and there are always commit flow alternatives. This is why I avoid it myself.
Re: Oh Shit, Git
#125Earlier quoted context omitted.
It's needed when you're somebody who doesn't want to spend their life in git and just want to undo a mistake.
It's not going to help when one fucks up a complicated merge/rebase and can lose a ton of work if something goes wrong. Understanding what you're doing goes a long way. I've seen this a couple of times at $DAYJOB when someone doesn't understand how rebase works, smashes keys until it looks like they've achieved their goal, and then I have to ssh into their box and try to unravel the damage they've done, hoping that r…
A 1000x this. I'm unfortunately that guy. I've learned never to use rebase and to copy and paste important code to a separate text editor (or use my IDE's separate undo cache) before trying a complex merge, and then just trying all over again if I fuck up.
That's easier than trying to get git working right, lol. It feels like every git command is a PhD rabbit hole. All I know is that if I screw something in git, trying to fix it will just screw it up worse. Reset early and often and it usually works in the end. Lol, it's terrible...
Re: Oh Shit, Git
#126> [git reflog … git reset…] You can use this to get back stuff you accidentally deleted Pro tip - this is true for commits, but not for accidentally dropped stashes. This is why it’s better to commit first, branching if necessary, than to stash. “If you mistakenly drop or clear stash entries, they cannot be recovered through the normal safety mechanisms. However, you can try the following incantation to get a list of…
This is my main reason to use Intellij - it tracks all changes without having to commit them. There must be a vscode plugin to do the same, but I dont know of it.
Re: Oh Shit, Git
#127I find people are religious about being git cli purists and only interacting with it in this black box (the terminal). On top of that a lot of people stop learning git after add commit push pull branch and merge so concepts like rebasing and cherry picking are scary. In this day and age we have state of the art GUI tools that change the game and allow git users to see and interact with the state of a git repository i…
As a counter point. Every time I've seen people get themselves into trouble with git has been when they are using a GUI tool. I have yet to see a gui tool that they can use to get themselves back out of it. There's a lot of value in knowing your way around the command line side of git even if you regularly use gui tools to interact with the repository.
I've had the exact opposite experience. I've had to bail out cli purists because they just can't see what went wrong.
Objectively git kraken has more visual information density. To get the same information on the cli requires multiple commands and the user has to hold the information I'm their head between the commands.
Git kraken's buttons are also tightly correlated to commands and you can even bring up a window that shows what cli commands are being run under the hood.
Re: Oh Shit, Git
#128I find people are religious about being git cli purists and only interacting with it in this black box (the terminal). On top of that a lot of people stop learning git after add commit push pull branch and merge so concepts like rebasing and cherry picking are scary. In this day and age we have state of the art GUI tools that change the game and allow git users to see and interact with the state of a git repository i…
Totally agree. Using git with a UI is much more enjoyable, albeit less purist but who cares. I'm working on 4 different features, more important to be efficient than pure.
Re: Oh Shit, Git
#129Earlier quoted context omitted.
To a large extent, yes. But when you find yourself stopped at a red light on a steep upgrade, and some idiot behind you decides to wait for the light three inches from your back bumper, things will go better when the light turns green if you have a decent mental model of the physical mechanism of the clutch. Sometimes you want to let those abstractions leak a bit.
They'll go even better for you if you just have good skill with the clutch - regardless of how it works or not.
Agreed, I’ve only recently learned (at a high level) how a clutch works, and it has zero impact on how I use it on the street.
Even off-road, I really only need to know to not ride it all the time.
Re: Oh Shit, Git
#130Earlier quoted context omitted.
I think this is what can confuse people. We have to face the facts that not everyone will need or be able to grok all of what goes on in git and what makes the car go forward. We can all drive that car still! Take the recursive merging stuff around minute 39. Do I need to know why git's model for merging is so much better and how it works its magic? I don't think so. It's an implementation detail. Do I need to know h…
To a large extent, yes. But when you find yourself stopped at a red light on a steep upgrade, and some idiot behind you decides to wait for the light three inches from your back bumper, things will go better when the light turns green if you have a decent mental model of the physical mechanism of the clutch. Sometimes you want to let those abstractions leak a bit.
Actually you don't need a mental model of the clutch at all for that. You just need to know how to handle steep inclines. There's a technique for that. All you need to know for that is the fact that on a steep incline you will go back a bit until your clutch has a chance to get you moving forward against the hill and that in this case you need to apply that technique. Like knowing when to use rebase, when to use cherry-pick etc. Now why you will roll back on the steep hill is not something a normal operator of a car needs to understand. Neither the clutch part nor the gravity one actually.
Also, if he's literally 3 inches, I would say the best approach is to slowly ease off the brakes until you actually touch the other car but do it so slowly that it's not an impact. All without even pushing the clutch. Then you don't even need to use the brake while pushing the gas pedal trick, because the guy behind you is your brake pedal ;)