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

111–120 of 352 posts

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

#111

Post by brusch64 »

TickleSteve wrote: post #99
brusch64 wrote: post #84

Earlier quoted context omitted.

I've been using Subversion since 10 years or so and I've changed completely to Git, so I've got experience with it. For me Git was really a much needed upgrade to subversion. Working with branches (testing and production, we even have some repositories with multiple testing and production branches) are working like they are supposed to do. Changing commits (oops - I forgot to add one file) before pushing them to the…

So what problems exactly did you have with SVN? branches are branches in svn or git... your process may not have been correct, but lets not blame the tools here.. modifying commits is a big no-no for me, so thats not a drawback at all, the fact that its not possible in svn is a win for svn.

I really like modifying commits (as long as they are not pushed) - but I know that this is quite a controversial topic.

For one of our biggest projects branches in SVN didn't work at all.

We have multiple production, test and development branches and merge branches (features) from one branch to the other (development -> testing -> production). Sometimes we cherry pick a single commit to another branch.

In those days SVN wasn't so flexibel with branches as we wanted to (or we didn't understand it enough), so our workflow was much more rigid.

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

#112

Post by pluma »

brusch64 wrote: post #69
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…

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.

I've heard a lot of people who seem to know their stuff say that Mercurial is superior to Git in almost every way, especially when it comes to integrating with other tooling (i.e. Mercurial seems to have an API whereas automating Git boils down to spawning shell commands). This also seems to be why Facebook switched from Git to Mercurial: they needed to be able to check out individual folders from a branch and Git simply didn't provide any way to do that without first checking out the entire branch.

Be that as it may, it's a common misconception that the more popular tool is always the better tool. There are a lot of factors to a tool's success and the technical ones are generally far less important than most people think.

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

#113

Post by brusch64 »

ubernostrum wrote: post #95
brusch64 wrote: post #69

Earlier quoted context omitted.

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.

I don't know any of the other distributed version control systems. In an ideal world -- one where network effects of GitHub hadn't crushed all competition -- I'd get to choose Mercurial as my daily version-control system. It has similarities to git, in that both are largely user interfaces to a DAG, but its guiding philosophy and approach to the interface it exposes are far better in my opinion. In my opinion Git is…

>we now have close to half a century of evidence that no human currently living can use C safely How many operating systems are written in C ? How many of the more mainstream operating systems are written in other languages ?

You're right that C is the wrong tool for a lot of applications. But if you need total control and speed and power it still works for many projects.

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

#114

Post by breatheoften »

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…

Its true -- and actually the well designed gui that accurately depicts the graphical state of your local repository makes it far easier to learn the concepts behind git than does the command line. Distributed vc is conceptually nuanced, but not overly complicated -- the complexity of git really is in the interface wherein you are asked to map command line syntax into abstract operations that manipulate a state that you actually can't easily see from the command line. The value of having a graphical depiction of the state that's changing as you invoke operations should not be underestimated.

http://gitup.co

I love this tool -- it's honestly one of the best graphical tools I've ever used -- rock solid reliable -- intuitive, not leaky in the abstractions it represents -- and not limited to only "simple" operations. And with the graphical reflog history rollback view -- it's always really easy to back up however far you want if you mess up which gives great confidence as you explore the ui's features. Ive taken designers from "never used git" to confidently pushing, pulling, rebasing, and resolving conflicts in less than a day (and most of it after the first 10 minutes without outside help).

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

#115

Post by SmellyGeekBoy »

TickleSteve wrote: post #90
Singletoned wrote: post #73

Earlier quoted context omitted.

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

not necessarily better than most other good engineers... He knows a lot about his domain, sure, but he's no god and there are a lot of areas he knows diddley-squat about.... user interface design for one!

I'm not sure why a kernel developer would need to concern themselves with UI design?

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

#116

Post by lambdacomplete »

Getting to "Fuck this noise, I give up." is a very clear indication that you aren't competent enough and you should take a GOOD course about git as soon as humanly possible.

Shameless plug: http://engineering.hipolabs.com/how-to-work-in-a-team-versio...

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

#117

Post by coldtea »

Grangar wrote: post #104
coldtea wrote: post #91

Earlier quoted context omitted.

> 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 dow I disagree. "spell X solves problem Y" is an excellent way to both get started with fixing your Y fast AND for learning a system deeper. I think we better learn by example (such as that) and in practical use over time, as opposed t…

I disagree. Using Git (or any terminal interaction for that matter) is much like speaking a language. As a metaphor: you might be able to order two beers in German (zwei Bier bitte), but the moment the waitress asks you what brand you want it comes down to guessing. Some coworkers (across all experience levels) use Git this way. It's frustrating how slowly they learn and conversely, how inefficiently they work.

>Using Git (or any terminal interaction for that matter) is much like speaking a language

Which again, we learn best by absorbing bits and pieces piecemeal over time -- that's how toddlers learn their native language, by immersion. Not by getting some "understanding of fundamentals" course first.

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

#118

Post by fmsf »

lambdacomplete wrote: post #116

Getting to "Fuck this noise, I give up." is a very clear indication that you aren't competent enough and you should take a GOOD course about git as soon as humanly possible. Shameless plug: http://engineering.hipolabs.com/how-to-work-in-a-team-versio...

Most of the problems can be solved easily if this is understood - Quote from that article - "Absorb that, internalise it, make it your mantra for the rest of your life or career: a git repository is a tree. "

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

#119

Post by edem »

I really like this article but there is a problem with it: what happens if I use one of your techniques and I screw up? These steps you describe are a black box to someone who is no git savvy yet. While these definitely help but they propagate the "git is scary, cross your fingers" mentality. What I mean by this is that the reader won't be any wiser after reading

> git reset HEAD~ --hard

What is ~ after HEAD? What is --hard? Is there a --deep option as well?

So I think that you could upgrade this with some annotations over the cryptic parts with a little explanation. What do you think?

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

#120

Post by sillysaurus3 »

breatheoften wrote: post #114
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…

Its true -- and actually the well designed gui that accurately depicts the graphical state of your local repository makes it far easier to learn the concepts behind git than does the command line. Distributed vc is conceptually nuanced, but not overly complicated -- the complexity of git really is in the interface wherein you are asked to map command line syntax into abstract operations that manipulate a state that y…

Just ran `brew cask install gitup`, cd'd into my repo and ran `gitup`. Took about 60 seconds and so far it's quite impressive.

Clicking on a commit and pressing space brings up a view showing a github-style diff, a list of all changed files, and the complete commit message. Nice.

Thanks for the tip!

Post reply on HN