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

51–60 of 294 posts

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

#51

Post by inimino »

gumby wrote: post #12

I'm surprisedly the staging-area hate. Does it really violate peoples' assumptions? I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go.

As the author points out, it is an unnecessary primitive, once you learn about things like commit —amend, which you will inevitably eventually learn about anyway. Adding redundant ways to do the same thing is not the way to make a tool approachable.

The basic problem is that git was designed to solve Linus’s problems, and Linus’s problems are not your problems. However, because of network effects, most of us end up using the same tool.

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

#52

Post by jcranmer »

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 git operation because of the risk that I might lose my in-progress commits.

While the problems of git's UI is well-known, I don't think it's as appreciated that git's complexity generally discourages people from trying things out. I'm never really sure what could cause me to lose unpushed commits or uncommitted working files, especially with git's predilection for reusing the same verb to do slightly different operations for different concepts. In stark contrast, it's more difficult to get Mercurial to chew up your work without telling you [2], and it's easier to explore the command lists to see if there's something that can do what you want it to do.

[1] The repositories I'm working on involve submodules, which hg-git is exceptionally poor at supporting well. Even so, the list of git alias commands on the whiteboard is entitled "Forcing myself to use git before I rage-quit and switch to Mercurial."

[2] I have done it, though. Worst offender was discovering that hg qrefresh causes only those file changes to be committed, and files not mentioned are decommited to working-directory-only changes... which hg qpop happily deleted without warning me, causing me to lose a large patch. That was when I put the patch queue directory in version control.

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

#53

Post by jcranmer »

taeric wrote: post #22

If you requested save in your favorite GUI application, text editor, etc and it popped open a select the changes you would like to save dialog, you would rightly think just save all my changes already, dammit I'm sympathetic to what this is asking, but I have to feel that this would lead to much better practices for many people. I'd wager a ton of folks would be more "why in the world does it think I changed that?" t…

In my experience, the benefit you get is from giving you an editor to edit the commit message, which has a list of files changed, and can be cancelled in some way to abort the commit. Both hg and git can do this, so it's not necessary to have a separate command and staging area just to do it.

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

#54

Post by carussell »

sharp11 wrote: post #20

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…

This is one of the few things that Launchpad got right. jquery, for example, would be at launchpad.net/jquery, and your own work would hang off of that. GitHub went with inverted namespaces (user/repo) instead, where every personal fork is an island unto itself, and the world is worse off for it.

I had hope that GitLab would take the opportunity to fix most of the problems GitHub introduced (or at least a few), but they seem to be interested in just copying the mistakes and chasing the market segment made up of people who's only criteria begins and ends with like GitHub, but on-prem.

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

#55

Post by DigitalJack »

jcranmer wrote: post #36
gumby wrote: post #12

I'm surprisedly the staging-area hate. Does it really violate peoples' assumptions? I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go.

Coming from someone who learned hg well before git, and who's now being more or less forced to use git long after developing comfortable hg workflows, the staging area feels like a half-baked implementation of what it's supposed to be doing. I'm used to thinking of commits as atomic commits--roughly, each commit is the smallest change that atomically makes sense. So you should be able to use the staging area to build…

You should look up the stash command.

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

#56

Post by paxys »

gumby wrote: post #12

I'm surprisedly the staging-area hate. Does it really violate peoples' assumptions? I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go.

But why not use a mechanism that already exists - local commits. That way you also get a complete history of changes (including rollbacks), can write incremental commit messages, and can squash everything partially or completely at the end.

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

#57

Post by mrich »

OJFord wrote: post #50
gmueckl wrote: post #32

Earlier quoted context omitted.

90% of VCS commits are simple enough to not need staging in my experience. That you can stage your changes does not mean that you need to be forced to do that. This is the point the article tries to make: streamline the workflow, but do not remove the feature for power users (people like you).

I believe there's a flag to `commit` that effectively does `add .` first. I disagree with your statistic though - I can't tell you what the flag is precisely because it's almost never what I want; so I never use it and haven't learnt it. I think these things just vary with workflow.

Just for completeness sake, the command to do that would be

  git commit -a
It does an implicit git add -u (which does not add new files not yet part of the repo)

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

#58

Post by hinkley »

infogulch wrote: post #27
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'.…

Commit messages could just as easily be a policy requirement instead of a tool requirement. Maybe all the repos you interact with require a message for every commit, and that's fine. But maybe the default policy should be permissive. People might decide not to use any tool at all if this is the straw that broke the camel's back for them, and that's a worse outcome in my opinion. And, honestly, 90% of all commits I've…

I would rather go the other way. Commit messages should be modifiable by themselves. The idea that commit messages will be gotten right on the first try predates CVS and it’s just wrong.

Who hasn’t put the wrong bug number on a commit? You’re stuck with that. Who hasn’t confidently remarked that they have solved a problem and then discovered they haven’t? Commentary about a block of code needs to be a living document every bit as much as the code it refers to.

Two years from now when you’re trying to figure out what the hell you were doing in a block of code, the message is going to be wrong and everything you’ve thought about it since is gone, except what you can remember.

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

#59

Post by nhaehnle »

carussell wrote: post #35
gumby wrote: post #12

I'm surprisedly the staging-area hate. Does it really violate peoples' assumptions? I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go.

Partial commits through piecemeal staging is great as a poweruser's tool, like rebase. But it's beyond weird that anyone thought it was a good idea to make people deal with staging for every commit. It doesn't even have to go away. (And on that note, I'm bummed that the conclusion in the article is to do that, especially because everytime this comes up, there's an uproar.) But, jeez. Just tuck it away so futzing with…

Git doesn't actually make people deal with staging for every commit, though.

It's quite common to tell newcomers to always `git commit -a`, and `git add` for adding new files. That's pretty much exactly where SVN is/was, and nobody complained about that being complicated or onerous either.

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

#60

Post by slavik81 »

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'm never really sure what could cause me to lose unpushed commits...

Effectively nothing. By default, old, unreferenced data is only garbage collected after a month. If you screw up a rebase, the old commits are still there with the same hash they always had. You just need to point the branch at them again.

> ...or uncommitted working files

That's fair. If I'm unsure, I just stash or commit first. Anything that's in git can be retrieved.

Post reply on HN