I stubbornly stuck with Mercurial for a long time because of the complexity of git's UI. But when one moves beyond a few developers, the available tooling and extensive ecosystem for git makes it inevitable.
Oh shit, git: Getting myself out of bad situations
51–60 of 520 posts
Re: Oh shit, git: Getting myself out of bad situations
#52We 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…
Have you looked at git-filter-branch?
The BFG program in this guide [0] seems reasonably close to #2. I don't know if you would need to manually trigger garbage collection in the remote repo, or how you'd do that.
https://help.github.com/articles/removing-sensitive-data-fro...
Re: Oh shit, git: Getting myself out of bad situations
#53A git off my lawn moment: Every time I see someone complaining because they have to dive into the reflog to fix their own mistake, all I can hear is "I was operating my table saw without using a push stick and can't understand why I lost a thumb".
Friends don't let friends (especially those who don't learn how to use their tools) rewrite shared git history. If you don't understand rebase, amends, etc can do to your (and everyone else's) repo, DON'T DO IT.
Re: Oh shit, git: Getting myself out of bad situations
#54My last git mistake was pretty terrifying. I decided to try and go back to an old commit on a project on my local machine after about a days work. Somehow I ended up making the commit I wanted to revert to a new branch, then somehow tagged that branch with the name of the commit making git get angry and decide that branch wasn't valid. Then continuing in my ignorance I reset to that branch and tried to checkout only…
Glad you figured it out! Having that much work on a single branch is a process smell in itself, ideally you would have found a way to get that code into the repo before it became that large (break down the work into smaller chunks, hide behind feature flags if needed, etc.). Beyond what you just described, reviewing that much work is nearly impossible to do correctly.
At the very least, if you are going to have a long lived branch, make granular commits and push to a remote repo frequently. That will give you a distributed backup strategy.
Re: Oh shit, git: Getting myself out of bad situations
#55In 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.
The underlying system is well designed, but a user interface that allows you to get into a point where you can hose a repo is anything but.
you can always get back to what you had before unless you try really, really hard to destroy data
git reflog is your friend
Re: Oh shit, git: Getting myself out of bad situations
#56In 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 recently had one of those holy-crap-what-did-I-just-do-I-lost-everything moments... But then realized that my scrollback had a list of files and my IDEs (PhpStorm and WebStorm) both kept _local_ revision histories and I was able to restore everything I had done.
I've had a few cases where I accidentally removed a local change before committing it; using Time Machine you can still recover some files then. I wish more editors had built-in support for it, if you're trying to restore a local file, macOS's TextEdit has support for Time Machine.
Re: Oh shit, git: Getting myself out of bad situations
#57I always fight for people really learning git, because that's when it finally starts to get good. And I always tell people that git is not the tool that everybody should use. Most people just need a simple data storage with diff management, like Dropbox or SVN. But even after nearly 10 years, the pressure from the aint-nobody-got-time-for-that crowd is still there. I really, really hope that the git devs don't feel p…
They can certainly provide much better porcelain out of the box. Mercurial is at least as powerful as git, but I always joked that the learning curve between the two is something like, you read the docs for 5 mins and you'll know what the next 50 commands to type into hg. Whereas git, you spend 50 minutes reading the Pro Git book, just so you know what the next 5 commands should be.
Re: Oh shit, git: Getting myself out of bad situations
#58I've said this before, but the business leadership, and tech leadership, need to think carefully about whether or not they need all of the power of Git. This sums up my concerns: ----------------------- Here are some minor failure modes I’ve seen with Git: 1. a branch that stays open for many months, perhaps even a year (for instance, at Maternity Neighborhood) 2. data is erased for good because someone makes a mista…
> 2. data is erased for good because someone makes a mistake while using rebase
No. Just no. Please stop spreading FUD like it's candy. Git only deletes commits after a GC, which won't erase commits from reflog and will keep unreferenced commits for at least a month before deleting them. And rebasing generates new commits, leaving the old ones exactly how they were. If somebody lost a commit after a rebase, and nobody nearby could help them recover it, they should consider spending a few hours learning about git.
I've been using git for 4 years both at work (with a team of 40+ people) and at home, without ever having any of the problems listed here (except 3 which has nothing to do with git). It takes a few hours, maybe a few days to understand how git works and how to use it. Instead of blaming the tools, you (and your team) should probably learn how to use them.
Re: Oh shit, git: Getting myself out of bad situations
#59Adopted 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…
What GUI do you recommend? My experience has been that GUIs are the easiest and fastest way to make a mess that can't be corrected without dropping to CLI or re-cloning. (I'm looking at you SourceTree). I've long recommended that everyone who uses git know how to use the CLI even if they don't use it regularly.
Re: Oh shit, git: Getting myself out of bad situations
#60Nice. For anyone who hasn't see it, Flight Rules for Git is even more comprehensive: https://github.com/k88hudson/git-flight-rules
I'm planning on making a hard push for git on the team I just joined (that isn't using any VCS). This and OP are going in my bookmarks.
> I'm planning on making a hard push for git on the team I just joined
You mean a force push. `git push --force` is one of my favorite commands. I've aliased `git yolo` to `git push --force --no-verify`.