Live data from Hacker News

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

ohshitgit.com

61–70 of 352 posts

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

#61

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 softwar…

  > just happened to win the PR battle against its superior foes, because...Idunno, Linux, I guess?
I would assume GitHub is to blame for that

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

#62
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.

Simplifying things a bit, git is what you did before you learned about using version control. That's right, it's just the old copy/paste the entire project folder for each revision and give it a name like "Project v1", "Project v2", etc. Branches and tags are then just symlinks to a specific folder.

In this world, when you commit, you're doing two things: 1. Creating a new top level folder, e.g. "Project v42". 2. Updating the branch symlink you are on to point to that new folder.

I'm actually not simplifying things that much here, the main git addition is that each folder (revision) also has a list of previous folders (revisions) and that the folders (revisions) are not named sequentially, they are named based on a hash of their contents.

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

#63

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…

Agreed, a GUI have most of the functionality and a clear visual representation of the state of your repo. When it's not enough the terminal is once click away

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

#64
Nobody likes to read manuals or books, due to which one can see FAQs being posted on Q&A sites.

http://gitready.com/ contains a number of small articles categorized by beginner, intermediate and advanced that might be helpful.

Another resource for commonly used git tips and tricks: https://github.com/git-tips/tips

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

#65

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 softwar…

I'm struggling to see which VCS you deem superior, I'm assuming you are not referring to SVN, Mercurial maybe?

The learning curve to git is not great but as far as I know nobody has publicly released an option that's improved enough over git to motivate the cost of switching technology. If it's not working for you the only advice I can give is either learn it until it is actually working for you rather than being in the way or try to find a better workflow.

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

#66
post #31
post #6

'sudo rmdir'? I don't think that does what they think it does.

For posterity, `rmdir` will only remove empty directories. The author presumably should have used `rm -rf`.

Or maybe

  sudo rm -rf /some/path --no-preserve-root

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

#67

Surprised there was nothing on messed-up merges or rebases. They're some of the worst to get out of when you're not totally comfortable with git yet.

Any points on how to continue from there? Been in a few "I give up" conditions during rebases that I completely stopped trusting git it any way.

The thing is, some repositories on github require you to commit only after proper rebasing. But I can never in my life remember how and need to google it...

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

#68
post #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 :)

> Ironically, all dot files have stuck as obvious :)

Those wouldn't have if you had set the following:

  shopt -s dotglob

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

#69

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 softwar…

What are the superior foes in your opinion ?

I don't know any of the other distributed version control systems. The only other version control system I have much (too much) experience with is Subversion and it can't hold a candle against Git.

In my opinion Git is the C language of version control systems. If you are careless it's not the tool for you. Otherwise you have a really great tool with lots of power.

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

#70
post #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, 1…

I think you misunderstood @mathieuh's statement, which is why you are being downvoted.

@mathieuh was only referring to not being able to break the something in the repo, He didn't mention hacking the git or the git data structure.

Also, @mathieuh is a uni student, so comments like

> This tells me you still don't get the point about using a revision control system

Can come across a little unnice.

Post reply on HN