Live data from Hacker News

Some bad Git situations and how I got myself out of them

ohshitgit.com

51–60 of 352 posts

Re: Some bad Git situations and how I got myself out of them

#52

I don't know if this post was intended as humour or a way to vent out some frustration but in my experience, this path of treating git as "spell X solves problem Y" will always break down. Version control systems are an important part of the programmers toolkit and it's worth investing a little time to get the fundamentals right. Sure git is not the friendliest of beasts but what it lacks in interface, it more than m…

Knowing Git "inside out" is great, but you can't expect to know/remember every command for every situation from day one or even day one thousand. A list of ways to solve Git problems serves as a refresher and even a tool for gaining more insight into how it works as a whole.

Re: Some bad Git situations and how I got myself out of them

#53
post #42

Yep, git sucks but it's all the rage now. Mercurial is 100x nicer to use and logical, but since it's written in Python it's slow as molasses, especially with large binary files. Next on the list: Larry McVoy's Bitkeeper promises to be everything git and Mercurial aren't. (git is "inspired" (read: copycat) by Bitkeeper). It's funny how Sun Microsystems influenced the industry in so many ways, isn't it?

For anyone who wasn't aware, it's also open source these days - http://www.bitkeeper.org/

Re: Some bad Git situations and how I got myself out of them

#54

I absolutely love git now. I'm still at uni (at a highly ranked but actually crap university where we don't learn git properly) and this year was my 'year in industry' as we call it in the UK, and my first proper experience with git, aside from `git init` at the end of my project and pushing it to a repo. I've become so much more confident with git. Seriously, with one caveat (i.e., you haven't pushed your changes to…

it is almost impossible to break irrevocably.

This tells me you still don't get the point about using a revision control system: the whole point is NOT that you can hack the revision control system's database every which way, but that you can never, as in ever, break something in a repository, because you can always revert the previous commit and do a new commit of that revert. Keeping it simple since January 1st, 1970.

It's called the "unceremonious revert", popularized by Jeff Bonwick, the father of ZFS and former Solaris gatekeeper, in the "Quality death spiral":

Bonwick was granted authority to "rip it out if itʼs broken" — an early BDFL model, and a template for later generations of engineering leadership.

https://web.archive.org/web/20091028095830/http://hub.openso...

https://wiki.smartos.org/display/DOC/Community+History

SEE ALSO

http://dtrace.org/blogs/bmc/2015/09/03/software-immaculate-f...

...and do youserlf a favor, try out Bitkeeper (it's open source!) before you get completely absorbed into git. You might never be able to get out of that tar pit afterwards, or it might be decades before you realize it. Who will compensate you for all that lost time, and how would you be compensated?

Re: Some bad Git situations and how I got myself out of them

#55

I can't believe no one has responded yet with "use a GUI". After gaining a basic understanding of how branches and merges work, and I do mean basic , I've never been able to screw up a local repo with a GUI client enough that I haven't been able to recover with the same GUI tools. I understand that people need to know how to use their tools, but for git most people can get away with the very basic usage that GUIs pro…

I like to use a GUI for things like viewing staged/unstaged files, their riffs, and picking which files to stage for a commit, but for every other situation, the command line is just so much faster and easier to understand what's actually happening.

Re: Some bad Git situations and how I got myself out of them

#57
post #18

Earlier quoted context omitted.

I think there's a bit of that in git in particular. The irony is that if you think of git in terms of deltas, with branches just being tags to commits, and "git commit" actually being "git commit + move branch", then a lot of stuff is easier to reason about. Like, if you get the notion of working tree, staging area, commits, and branches on a deep-ish level, things get easier. Things can still be hard, but there's a…

> and "git commit" actually being "git commit + move branch" Can you elaborate on that a little more? I liked where it was going -- because being able to explain how git works to someone coming from SVN has been an ongoing problem for me.

In git, branches are pointers to commits (branches are a specific kind of refs or references). When you commit, git creates a new commit object, links it to the last commit on that branch, and then points that branch to the new commit.

This way, you get a chain of commits, each pointing to the previous commit, and and branch references pointing to the last commit of each branch.

Re: Some bad Git situations and how I got myself out of them

#58

I don't know if this post was intended as humour or a way to vent out some frustration but in my experience, this path of treating git as "spell X solves problem Y" will always break down. Version control systems are an important part of the programmers toolkit and it's worth investing a little time to get the fundamentals right. Sure git is not the friendliest of beasts but what it lacks in interface, it more than m…

"Not the friendliest of beasts" is putting it mildly.

Git is basically Linus in a nutshell: abrasive, unforgiving, and behaving like an absolute asshole to any non-expert struggling user.

Sure, engineers should probably get to know its quirks and learn to work around them because it's now ubiquitous in the field, but let's not pretend that there's something virtuous about it. This is a piece of truly terrible software with an even worse UX that just happened to win the PR battle against its superior foes, because...Idunno, Linux, I guess?

Re: Some bad Git situations and how I got myself out of them

#59
It's probably a good time to check if you have some safety against `rm -fr `.

Two days ago, I wanted to delete .git only, but accidentally as my fingers were accustomed with -fr , the command was `rm -fr * .git`. Rails server was running and some hope arose at the moment to just `lsof | grep` .. unfortunately that didn't work with me !

Ironically, all dot files have stuck as obvious :)

Re: Some bad Git situations and how I got myself out of them

#60
post #49

If you're concerned about not knowing how to do certain things with git, and understanding at a deeper level how git works, I highly recommend reading Scott Chacon's "Pro Git" book: https://progit.org/

I second your recommendation, this book has saved my bacon multiple times.

But does anyone know why this project has two homes?

https://git-scm.com/book/en/v2

Post reply on HN