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

High-Level Problems with Git and How to Fix Them

gregoryszorc.com

Post reply on HN
Print view View original

11–20 of 294 posts

Re: High-Level Problems with Git and How to Fix Them

#11

Post by klodolph »

It's clear that there will be a successor to Git some day, in the sense that Git is a successor to SVN (yes, I know Linus's viewpoints on SVN). But the successor won't be a "better Git" just like Git isn't a "better SVN".

The driving features of Git's successor will be unrelated to Git UI gripes. If Git's UI gripes were important enough, people would just be using Mercurial (which has it's own quirks). The biggest problems I've personally seen with Git are the same problems you see with other VCS, where two people change the same file, and one commits the changes first. Now you have to merge the changes and sometimes it's a pain in the ass when you just want to submit your changes and go home. A better VCS isn't going to solve that!

I'm still glad that Git delivered me from all the merging problems that SVN had, although I've heard that SVN is a little better these days.

Re: High-Level Problems with Git and How to Fix Them

#13

Post by BurningFrog »

influx wrote: post #7
bluetwo wrote: post #2

I've just never found a reason to move on from SVN, to be honest. I use GIT when I am forced to, but for everything under my control, SVN works the best. I was unaware you could get rid of the staging area in GIT. I may need to look more into that.

Git is over complicated for most people’s use cases, but I wouldn’t give up the fast branching and the rebasing features.

GIt is only as complicated as you make it. You don't have to use all the features :)

Re: High-Level Problems with Git and How to Fix Them

#15

Post by y7 »

gear54rus wrote: post #6

The general sentiment of this article is in things like: > A commit message is already too annoying for many users! So because your ass is just lazy another guy a few months down the road has to suffer (in this case decipher what it is you wanted to do with your changes)? Put some damn effort in, we have enough crapware already, we don't need to add more just because you were 'annoyed by having to document changes'.…

You can use Git for things other than open source software development.

Re: High-Level Problems with Git and How to Fix Them

#16

Post by arunc »

klodolph wrote: post #11

It's clear that there will be a successor to Git some day, in the sense that Git is a successor to SVN (yes, I know Linus's viewpoints on SVN). But the successor won't be a "better Git" just like Git isn't a "better SVN". The driving features of Git's successor will be unrelated to Git UI gripes. If Git's UI gripes were important enough, people would just be using Mercurial (which has it's own quirks). The biggest pr…

Personally, the problems I have with git are related to the fact that none of my coworkers use git. If I mess up my repo I don't have anyone to look for. The experience with mercurial is exactly the opposite. I never needed to look for "experts" to solve a problem in mercurial. hg help is all I needed. Consistent UX and safe and powerful VCS is all we need.

Re: High-Level Problems with Git and How to Fix Them

#17

Post by Klathmon »

klodolph wrote: post #11

It's clear that there will be a successor to Git some day, in the sense that Git is a successor to SVN (yes, I know Linus's viewpoints on SVN). But the successor won't be a "better Git" just like Git isn't a "better SVN". The driving features of Git's successor will be unrelated to Git UI gripes. If Git's UI gripes were important enough, people would just be using Mercurial (which has it's own quirks). The biggest pr…

> A better VCS isn't going to solve that!

It might!

I feel like a "language aware" VCS would be able to help a lot in this area.

I know there are 3rd party tools that can do this, but if a VCS came along that natively knew about some languages it could unlock some really cool features.

Imagine instead of your VCS storing the text source, it stores the AST! Language aware means it can also integrate tightly with language package managers.

Re: High-Level Problems with Git and How to Fix Them

#18

Post by mikeyjk »

klodolph wrote: post #11

It's clear that there will be a successor to Git some day, in the sense that Git is a successor to SVN (yes, I know Linus's viewpoints on SVN). But the successor won't be a "better Git" just like Git isn't a "better SVN". The driving features of Git's successor will be unrelated to Git UI gripes. If Git's UI gripes were important enough, people would just be using Mercurial (which has it's own quirks). The biggest pr…

I mean, you could just checkout a new branch and push that, right?

Re: High-Level Problems with Git and How to Fix Them

#20

Post by sharp11 »

Lots of food for thought in this article, but the part I find most interesting is his distinction between "soft" and "hard" forks. (Viz., are you "forking" in order to collaborate or in order to go your own way?)

If collaborate, it would be nice to lower the barrier to participation ... more like Wikipedia. I know that I often don't bother to submit a PR for small changes bc of the overhead of setup. Whereas I fairly often make small edits to Wikipedia changes, because it's so easy.

Post reply on HN