Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ohshitgit.com

Post reply on HN
Print view View original

71–80 of 352 posts

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

#71

Post by pjc50 »

wkd wrote: post #65
ewjordan wrote: post #58

Earlier quoted context omitted.

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

SVN is much easier to use for the standard corporate workflow of a group of people making commits to a project which mostly advances monotonically with continuous integration.

Edit: also in a Windows environment, svn copes slightly better than git. First project we tried it on had the worst possible environment, a mix of Windows and Linux systems. Line ending nightmares everywhere.

It also took a while to work out how to kill (with fast-forward) the spurious "merge commit" you get every time someone does a pull. You don't have that with svn, you just do the merging locally when you update and it doesn't generate a commit.

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

#72

Post by K0nserv »

eyelidlessness wrote: post #34

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 have to disagree, I've seen people paint themselves into really hard to get out of corners by using GUI tools and not understanding the underlying tool. git GUIs are leaky abstractions that sometimes even change the meaning of core git concepts. I always recommend people start by using git at the command line until the have a solid understanding of how the tool works before switching to a GUI.

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

#73

Post by Singletoned »

ewjordan wrote: post #58
noufalibrahim wrote: post #12

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…

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

You forgot "brilliant".

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

#74

Post by tempodox »

ewjordan wrote: post #58
noufalibrahim wrote: post #12

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…

> ... that just happened to win the PR battle ...

Chalk that up to the power of fashion. Otherwise, people would use an SCM that doesn't destroy their work in the blink of an eye and actually has an API that deserves the name.

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

#75

Post by ekimekim »

random567 wrote: post #2

The screwed up and committed to master should end with: git reset --hard origin/master (assuming that the remote is called "origin") With the example in the text, you have to know the number of commits you've made to master.

tip: you can use @{u} to refer to "the upstream of my current branch", ie. what you said but will work no matter what the remote is called.

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

#76

Post by tempodox »

pjc50 wrote: post #71
wkd wrote: post #65

Earlier quoted context omitted.

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…

SVN is much easier to use for the standard corporate workflow of a group of people making commits to a project which mostly advances monotonically with continuous integration. Edit: also in a Windows environment, svn copes slightly better than git. First project we tried it on had the worst possible environment, a mix of Windows and Linux systems. Line ending nightmares everywhere. It also took a while to work out ho…

I concur. I would assume that git is the right tool for Linus's workflow, but whatever that is, it isn't mine. SVN does all I need and it has a friendly API and helpful documentation. In other words, the exact opposite of git.

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

#77

Post by tech2 »

mcv wrote: post #47
noufalibrahim wrote: post #12

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…

I think the biggest problem people have with git is that you can't and shouldn't want to change shared history, and yet git provides some tools that suggest that maybe you can. It's better to accept history as it is, and fix the problem with reverts, cherry-picking and new commits. History won't be as pretty or clean, but it will reflect what actually happened, which is what history is, after all. The biggest trick t…

> but it will reflect what actually happened, which is what history is, after all.

Recorded history is not necessarily what actually happened though, often (or always, according to some) it's an interpretation.

"History is written by the victors" - Walter Benjamin?

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

#78

Post by lordnacho »

eyelidlessness wrote: post #34

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 agree. If you use something like SourceTree, you can also see the git command, in case you end up needing to know what it is. Best of both worlds.

I mainly use the GUI for day-to-day stuff. Only in rare cases will I need to mess with the command line.

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

#79

Post by lordnacho »

Surprised he finds git to be complicated. It probably is deep down, but for day-to-day use, compare it to SVN.

Until I switched, there was always a panic when branching or merging. With git, I can branch like a nutter and things seem to still work out in the end.

Not sure why, perhaps someone else has a perspective on it.

Post reply on HN