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

91–100 of 352 posts

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

#91

Post by coldtea »

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 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 to getting some abstract knowledge of the whole system first, or (god forbid) reading the manual, which noone does.

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

#92

Post by skissane »

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…

I think the ability to edit history is one of the great advantages of Git. I encourage people to use it rather than ignore it.

Cleaner history makes life much easier for those who will try to understand what you did weeks or months or even years later (including your future self).

Of course, you shouldn't (with rare exceptions) edit history you have already shared with others; but, I never found that concept, or the way git implements it, particularly hard to understand. (I will admit some of git's commands are hard to remember - I am always forgetting the difference between "git reset --hard" and "git reset --soft".)

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

#93

Post by TickleSteve »

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.

Can you justify git>subversion or are you just following the sheep?

Not saying I disagree... but subversion is still king in the corporate-engineering companies and it tends to work well in those types of setups.

Just beware of having unjustified-opinions. SVN may not be trendy... but neither will git in a few years time.

BTW: Mercurial still beats them all.

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

#95

Post by ubernostrum »

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 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 the C language of version control systems. If you are careless it's not the tool for you.

You probably don't want to make that assertion; we now have close to half a century of evidence that no human currently living can use C safely, and I don't think you'd want that to carry over to git. And it's not a matter of "careless" or not -- extremely intelligent, extremely-well-trained, extremely-careful people still write unsafe C.

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

#96

Post by Singletoned »

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!

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

And Einstein knew nothing about biology.

I'm sure he knows "diddley-squat" about most areas, but as long as he knows a lot about his domain then he's an expert.

And he is good at user interface design, and git is a good example of that; it's just not aimed at beginners. It was designed by and for expert users, and the interface fits that very well.

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

#97

Post by ZeroGravitas »

l0b0 wrote: post #82
mcv wrote: post #47

Earlier quoted context omitted.

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.

Ah, interesting. I'd noticed this behaviour but hadn't conciously thought about it.

The docs say:

All changes made by commits in the current branch but that are not in are saved to a temporary area. This is the same set of commits that would be shown by git log ..HEAD

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

#98

Post by Pica_soO »

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…

Oh, i did, yes i did. I wish there was a refund on wasted life. Process Explorer- are those crashed git instances still around? Yes. Can i kill them now with admin priv? Nope. Gui still frozen? Yes. Can i get Git-bash? Yes. Can i do something usefull with it? No, session is still open in the gui.

No, don't get all riled up. I know what you will tpye beneath this. "..Put all the dummys in a reeducation camp, with electric fences around it.." ".. cementing superiority is what is all about, fuck the specialization that got humanity this far.." didn't sound like a opinion that can change the last time.

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

#99

Post by TickleSteve »

brusch64 wrote: post #84
pjc50 wrote: post #71

Earlier quoted context omitted.

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…

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.

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

#100

Post by rakoo »

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!

Hah, so just like git then.
Post reply on HN