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

81–90 of 352 posts

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

#81

Post by [deleted] »

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…

[deleted]

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

#82

Post by l0b0 »

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…

`git rebase -i` by default rebases only back to the first commit you haven't shared (at least that's how I interpret the actual behaviour). This is a great default - it's the simplest way to change history and at the same time powerful without being too dangerous.

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

#83

Post by froh42 »

With all these recipies - one thing I do whenever I attempt some stunt in git: I assign temporary tags to every changeset that's important.

    git tag tmp
    git perform-stunt
This eases undoing the stunt without needing to find the "before" state from reflog. And if you use a graphical log viewer (I like SourceTree on Mac) you'll see the tagged state in the history view - which makes things a lot clearer.

And to be aware what happens, there one single explanation of git that helps a lot: http://eagain.net/articles/git-for-computer-scientists/

As soon as you start viewing git as a graph of nodes with branches/tags just being "marked" nodes a lot of things make sense, and whatever "git perform-stunt" you attempt it's easy to explain within that mental model.

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

#84

Post by brusch64 »

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'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 repository for the other users is another big advantage. Working on multiple features in parallel - I couldn't do that with Subversion.

We've nearly completely eliminated the "handcrafted" local copies with multiple half finished features since changing to Git.

And if you want to use Git as a Subversion alternative you can use it in this mode too - altough you are missing out on some good new features.

I don't want to change back to Subversion.

The only disadvantage is that SourceTree (the GUI tool we are using) is a pretty lame duck in Windows. But the command line is excellent.

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

#86

Post by wyclif »

pawadu wrote: post #60
wyclif wrote: 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

My understanding is that the dedicated site above highlights the book itself, while git-scm.com recommends/promotes the book.

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

#87

Post by wfunction »

zubspace wrote: post #67
wfunction wrote: post #15

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

> Been in a few "I give up" conditions during rebases that I completely stopped trusting git it any way.

Been there too, with the same result.

> Any points on how to continue from there?

Honestly? Not always from the command-line, unfortunately. Basically, I just don't know the right commands to type on the command-line for everything I do with git, and it's not necessarily easy to find them either. I use the TortoiseGit GUI, and over there, it's a LOT more easy to see what is going on and to abort or continue rebases/merges as necessary, or to do fancier stuff. But the thing is, because I understand git and I know what should logically happen at every step, I can cherry-pick commits, revert them, abort/continue merges, rebase commits, or do whatever else the heck I want without getting into trouble anymore... even though I don't know how to do many of them on the command line.

Of course, it took a lot of suffering to get here. Starting with the GUI would of course be the wrong approach. But once you've understood what's going on, then I would recommend you entirely ditch the command line and switch to something like TortoiseGit (I hope you're either on Windows or your platform has something as good as that). The GUI actually shows you what your options are at every step, so you don't have to know all the valid commands at every possible state. You just need to know what effect you need to cause.

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

#88

Post by apk17 »

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…

SVN is a glorified backup - which is basically what you're saying.

The SVN UI is just horrid in other dimensions, mainly the "you can't do that at all" one.

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

#89

Post by screwt »

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'll second brusch64 here.

I used SVN for 7 or 8 years and then Git for the past 3, with about a year of overlap (on different repos).

To me, Git is vastly superior. I tend to use it in quite an "SVN-like" fashion - there's a single main trunk branch that we all share - but in terms of what I can do locally it blows SVN out of the water.

The difference is that Git makes things that are hard or impossible in SVN trivial. So for e.g. I create local branches all the time; I commit a bunch of small changes locally as I experiment with a fix, and then `merge --squash` to leave a clean history for others; merging fixes across different branches is easy and just works.

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

#90

Post by TickleSteve »

Singletoned wrote: post #73
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…

> 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!

Post reply on HN