Some bad Git situations and how I got myself out of them
51–60 of 352 posts
Re: Some bad Git situations and how I got myself out of them
#52I 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…
Re: Some bad Git situations and how I got myself out of them
#53Yep, 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?
Re: Some bad Git situations and how I got myself out of them
#54I 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…
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
#55I 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…
Re: Some bad Git situations and how I got myself out of them
#56alias gitshit="open http://ohshitgit.com/"
Re: Some bad Git situations and how I got myself out of them
#57Earlier 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.
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
#58I 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…
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
#59Two 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
#60If 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/
But does anyone know why this project has two homes?