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

131–140 of 294 posts

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

#131

Post by dmitriid »

One of the main problems I still face is: Git's CLI is incomprehensible. It's a tangled mess of poorly named commands with even more poorly named options.

If there's a "create" command, it's "modify" counterpart is likely to be "create -b -u -t --modify", and it's "delete" counterpart is likely to not exist at all or be an arcane incantation of several non-related commands and a push.

Unfortunately, most GUI tools are just thin wrappers on top of all this mess (with the possible exception of GitUp whose abstractions are also paper-thing at times)

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

#132

Post by chrisan »

hyperion2010 wrote: post #123

While many of these criticisms are valid, they seem to be written from the point of view of a user that doesn't really want control over their versions, they just want versions. I'd suggest that there are other tools for this, such as a properly configured ZFS setup which are atomic beyond most users widest dreams (especially if all the versions of a vim .swp file are retained). If you just want versions, yes, git ge…

Well said.

> Most people see version control as an obstacle standing in the way of accomplishing some other task. They just want to save their progress towards some goal. In other words, they want version control to be a save file feature in their workflow.

That was horrifying to me. We _religiously_ have a JIRA-XXX tag in our commits so that every commit has some kind of perspective in addition to the comment. This has been extremely useful in getting more context of why something was changed when dealing with a long lived project spanning multiple developers. Even if the commit message itself is weak or lazy we still have the user story in JIRA to get full context.

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

#134

Post by thomasahle »

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.

Apparently SVN has something like that now.

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

#135

Post by jhanschoo »

qznc wrote: post #116
jcranmer wrote: post #52

One personal anecdote: In a decade of using Mercurial, I've managed to get a repository in such a confused state that I had to blow it up and start from scratch just once. In the same time, I've had to do the same for git repositories at least 5 or 6 times--and I never really used git all that much. Even nowadays, where I'm more or less forcing myself to use git [1], I'm incredibly hesitant to try any sort of complex…

> In a decade of using Mercurial > I never really used git all that much Does not sound like a fair comparison ;)

It's a valid comparison for his point that Mercurial is much more reliable for his workflows than git.

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

#136

Post by jhanschoo »

jcranmer wrote: post #52

One personal anecdote: In a decade of using Mercurial, I've managed to get a repository in such a confused state that I had to blow it up and start from scratch just once. In the same time, I've had to do the same for git repositories at least 5 or 6 times--and I never really used git all that much. Even nowadays, where I'm more or less forcing myself to use git [1], I'm incredibly hesitant to try any sort of complex…

> I don't think it's as appreciated that git's complexity generally discourages people from trying things out.

The irony here is that the model that git internals use aren't really complex at all; it's the poor porcelain and poor naming that makes it seem complicated.

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

#138

Post by cannam »

This is a really interesting piece that introduced a number of ideas I hadn't ever thought deeply about, particularly in the section on nameless workflow. (I do think of myself as reasonably capable with both Mercurial and Git.)

If your instinctive response is to defend Git, boost Mercurial, ridicule people who can't use their tools, ridicule the tools for being unusable, or whatever -- suppress it for a while and give this article some thoughtful attention.

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

#139

Post by 3minus1 »

pritambaral wrote: post #126
arunc wrote: post #16

Earlier quoted context omitted.

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.

> I never needed to look for "experts" to solve a problem in mercurial. hg help is all I needed. Git has good documentation too. As long as we're doing personal experience, here's mine: I learned git from `git help` too (well, `git --help` and `git --help`), and I never needed to look for a git expert in my team for advanced operations; I did have to be one for others quite a few times , but when it wasn't an immedia…

Does anyone who's downvoting this comment care to explain why?

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

#140

Post by giomasce »

The thing I love of git is that its internal structure is very simple and transparent, so for any given repository it is possible (although not necessarily easy, if things are well messed-up) to understand what is going on. It is true that the interface is often messy and inconsistent, sometimes annoyingly so, but if I can understand what things are, I can somehow work out how to do things with them (in extremal situations, I know I can fast-export everything, process with custom Python scripts, rather easy to write, and fast-import again). While if I do not understand what things are, the most powerful and user-friendly tool will have very little value to me. Also, knowing what is git under the hood makes me very confident that I will not lose pieces: as soon as the hash of my interesting commits is in another repository (which is not corrupted), I can do whatever I want with the first one and everything I care will be safe anyway.

All of this depends on me knowing what happens inside git and the git insides being rather simple (a hash tree with a handful of object types); I think I would like Mercurial (or any other DVCS) much more if I knew the same about it: can someone suggest places where this is described?

Post reply on HN