In three years of using git I believe there is a single bad command that I could not undo: `git checkout -- somefile` The second worst thing I did is losing a commit in a `git rebase -i` but I was able to find it back with `git reflog`. Which makes me think that git is really well designed.
I'm a big fan of 'git checkout -p'. Even if you nuke a hunk you actually wanted, it's not actually gone until it falls off your scrollback buffer.
Oh shit, git: Getting myself out of bad situations
251–260 of 520 posts
Re: Oh shit, git: Getting myself out of bad situations
#252Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…
The Git UI that comes with intelij can do all the essentials git statements and has a console that logs everything it is doing.
And you can also learn useful things by reading the console sometimes. There is no magic.
Re: Oh shit, git: Getting myself out of bad situations
#253We pushed large binaries into our git in the past. This was fine-ish as long as Git was hosted inhouse, but now that it's SAASed out, they are a huge pain in the rear. I've browsed through a few git guides, but can't seem to find anything that would let me: 1) Do something like "du -s *|sort -n" for the entire Git history 2) Let me "rm -rf --from-history-too", that would cause the remote repo to actually shrink in si…
For part 1 - I used this https://stackoverflow.com/questions/13403069/how-to-find-out...
Which for part 2 then leads to the BFG repo cleaner (which I haven't used)
Re: Oh shit, git: Getting myself out of bad situations
#254Earlier quoted context omitted.
rebase can be dangerous, but so productive. I think it's important to teach new devs how to properly use it. Especially if you're working in a continuous deployment environment, where you may need to quickly revert something.
Reverting something does not require a rebase. It requires an aptly named command "git revert". Additionally, in the event that a deployed feature needs to be reverted, any halfway decent change management policy will want a history of what you reverted and why; a git revert commit can show both very cleanly. And, frankly, since all rebase does is re-write history, I fail to see how it's inherently productive, especi…
Rebase is mostly useful for cleaning up local commits or feature branches. You can rebase without force pushing master.
Re: Oh shit, git: Getting myself out of bad situations
#255Earlier quoted context omitted.
I use both - to me the big advantage of getting used to GIT CLI is that you learn the tools to handle uncommon operations and automate tasks, which the GUI doesn't give you. When you need to start piping stuff through grep, for example.
GUI user here. Genuine question: when would you need to pipe stuff through grep? I get it would be a rare situation, but I can't think of one.
We have a naming convention that feature branches are named "feature-[descriptionOfFeature]" here and I wanted to bulk-delete all the merged feature branches that developers had left dangling, without killing the release branches and the like. Grepping helped there.
Like I said, super-rare situation.
Re: Oh shit, git: Getting myself out of bad situations
#256On barrier to learning git is that people are understandably reluctant to try things out because they are working in real repositories.
This site makes a game out of learning git: https://learngitbranching.js.org/
It's a great way to learn without putting your real repository at risk.
Re: Oh shit, git: Getting myself out of bad situations
#257In three years of using git I believe there is a single bad command that I could not undo: `git checkout -- somefile` The second worst thing I did is losing a commit in a `git rebase -i` but I was able to find it back with `git reflog`. Which makes me think that git is really well designed.
When in doubt either:
* commit to an itermediate branch as storage
* git stash && git stash apply (repeat last to recover stuff)
Re: Oh shit, git: Getting myself out of bad situations
#258Earlier quoted context omitted.
" Instead of blaming the tools, you (and your team) should probably learn how to use them. " From the essay: -------------------- And Git is intimidating, not just to non-technical staff, but also to inexperienced programmers. In How To Destroy A Tech Startup In Three Easy Steps I talk about Sital, and his unwillingness to commit things to Git. He was learning a great deal about many other technologies, and he didn’t…
> He was learning a great deal about many other technologies, and he didn’t have any spare energy to learn about Git. Git is something that you can use on almost any project, with any team, at any company. It's something you need to use if you want to contribute to open source. Aside from your programming language of choice, it's probably the second most useful tool you should be learning as a software developer. You…
* Your attitude is the exact opposite. *
You setting your theory against my lived experience. If you want to understand the situation more fully, you can read How To Destroy A Tech Startup In Three Easy Steps:
https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...
I did my best to re-create the extent to which decisions were driven by panic and the pressure of time.
Please note, every company in the world has a finite amount of time, and a finite amount of money. You can argue that a company should hire people with more experience, but people with more experience will be more expensive, so you will end up with less people. Or you can argue that a company should hire more people, of less experience, and then train them. Training takes time, so in this case you are trading time for money.
All of these strategies work, but in different circumstances. In the circumstances that I faced in 2015, described in the book, I advocated for the strategy of less people, of a higher skill level. I was, however, outvoted, which is a reality of corporate life.
It is relatively rare that a company follows an ideal strategy. What I see instead is constant course correction, often with a bit of a lag, so that the company ends up having the ideal strategy for dealing with the situation that it faced 6 months ago, which is not necessarily the ideal strategy for what it is facing now.
Business tends to be chaotic. The Platonic Ideal of computer programming needs to be adjust to the real realities that businesses face.
To be clear, Sital's attitude was a major problem, and myself and co-workers advocated that he be fired. But management kept him on, and I was given the responsibility of covering for the gaps in his knowledge. I was not happy about this, but this is a reality of business: we often have to accept that a decision has been made that we strongly disagree with, and then we need to somehow make the best of it.
Re: Oh shit, git: Getting myself out of bad situations
#259Adopted a git GUI years ago and haven't looked back. I get looks sometimes, but I can't help but gloat when I can stage and unstage individual lines in less than a second. I think anyone who uses the CLI is either trying too hard or hasn't realized the beauty of a git GUI. Takeaways: - My commit time is usually much faster than coworkers, with higher accuracy (less frequent accidental commits, etc.) - I don't remembe…
I wouldn't say "anyone" is trying to hard but I have seen a lot of people who immediately disregard guis as soon as they internalize that the cli is more difficult. Reasons include wanting to be "badass" or "smart". Yet many also do not care about how got differs and basically ask "how do I save" and proceed to revolve their entire workflow on a few copy pasted or memorized commands.other they hear how "rebase" is only for "smart" people...
On the opposite side gui users can often be unaware of the actual model and instead be working with imperfect internal models with be GUI being a crutch.
In both cases there is lack of desire to learn but I'm often more sympathetic to the latter where people want just enough information to do their work well as oppossed to the former who often make things harder than they have to be in all areas and have lost touch with true expertise in favor of appearance of expertise.
Re: Oh shit, git: Getting myself out of bad situations
#260Thank you so much! These are pretty useful tricks. Just a question: What's the difference between reflog and using git log to later checkout to a given commit?
You almost never checkout to a commit. You checkout to a branch. A branch is a reference to a commit, and the HEAD is a reference to a branch. The HEAD is where you are right now. When you make the HEAD point to a specific commit, you're in a 'detached head' state.
`git log` tells you all the commits that are part of the branch. More generally, they are the commits who are children of the current commit (the commit your branch points to).
`git reflog` tells you where your HEAD has been. When you change for branch to branch, the HEAD moves around. That history is recorded in the reflog. If you botch a rebase, your HEAD will sit on top of the newly created (and botched) commits. You can still access your previous commit by looking where the HEAD was before moving to the new commits made by the rebase.