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

91–100 of 294 posts

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

#91

Post by nhaehnle »

rbehrends wrote: post #26
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'.…

> 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)? The problem that Greg is referring to here is that `git commit` (as for many other version control systems) overloads two distinct operations: checkpointing your work and creating a new revision. Forcing you to provide messages for the former use case can even…

... so have a policy of all your "checkpoint" commits just having "checkpoint" as a message. Or ".".

Forcing a commit message is a good default, because it's a good idea to nudge developers towards properly expressing what they're doing. But if you think you know what you're doing, it's easy enough to work around.

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

#92

Post by Dylan16807 »

hinkley wrote: post #58
infogulch wrote: post #27

Earlier quoted context omitted.

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…

How do you like git-notes?

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

#93

Post by popopopo »

_pmf_ wrote: post #88
popopopo wrote: post #64

Earlier quoted context omitted.

wow. > I'm incredibly hesitant to try any sort of complex git operation because of the risk that I might lose my in-progress commits. correct way of learning git is every time you want to use a "complex"/dangerous commands in git, you `cd /tmp` and create a git repository there. then create some commits, branches and experiment. you will NOT lose anything, but you will learn a lot. I did and do this every time I have…

> when you accidentally kick a corner of a furniture, that does not make that furniture "dangerous". When the piece of furniture has a serrated corner that cuts deep into your toe, you'll probably reevaluate the appropriateness of your metaphor.

oh, so if you are careless, that's furniture's fault. okay. your comment is not the best counter to my point either.

PS: i have a lot of furniture with rought edges. I've learned my lesson, and furniture is not a problem anymore.

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

#94

Post by tudorw »

popopopo wrote: post #64
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…

wow. > I'm incredibly hesitant to try any sort of complex git operation because of the risk that I might lose my in-progress commits. correct way of learning git is every time you want to use a "complex"/dangerous commands in git, you `cd /tmp` and create a git repository there. then create some commits, branches and experiment. you will NOT lose anything, but you will learn a lot. I did and do this every time I have…

No but if occasionally the furniture kicks you, then it could be improved on, pointing out flaws in the best of the best is very worthwhile, it's in that pain space that the biggest usability gains are to be had.

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

#95

Post by therein »

enzanki_ars wrote: post #45
carussell wrote: post #35

Earlier quoted context omitted.

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…

I have ADHD, so often as I am working on one feature, I will begin accidentally working on another unrelated feature along side it. I rely on staging a lot to ensure that each commit has only the parts that it needs.

Same here, I actually find `git add -p` to be very useful.

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

#97

Post by icebraining »

jcranmer wrote: post #53
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.

List of files is not enough, I always do 'git add -p' to see the actual changes. And sometimes I detect an error, and I want to fix it and then keep going without having to re-evaluate the changes I had already seen.

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

#98

Post by BlackFingolfin »

blux wrote: post #69

The Git staging area doesn't have to be this complicated. A re-branding away from index to staging area would go a long way. Adding an alias from git diff --staged to git diff --cached and removing references to the cache from common user commands would make a lot of sense and reduce end-user confusion. --staged is already an alias for --cached in the latest Git version.

And it has been for some time (years, I think)

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

#99

Post by qznc »

paxys wrote: post #56
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.

I made myself a few alias to use this approach. After a few months of use I can say staging is practically unnecessary for me. There were a few edge cases, but maybe I was just falling back to known solutions. I'm in favor of dropping staging.

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

#100

Post by rbehrends »

nhaehnle wrote: post #91
rbehrends wrote: post #26

Earlier quoted context omitted.

> 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)? The problem that Greg is referring to here is that `git commit` (as for many other version control systems) overloads two distinct operations: checkpointing your work and creating a new revision. Forcing you to provide messages for the former use case can even…

... so have a policy of all your "checkpoint" commits just having "checkpoint" as a message. Or ".". Forcing a commit message is a good default, because it's a good idea to nudge developers towards properly expressing what they're doing. But if you think you know what you're doing, it's easy enough to work around.

Checkpointing is generally different from commits in more than just not having a commit message (ex: should one allow checkpoints to be pushed? should they be suppressed in the log by default? should they be part of the normal revision graph or a separate hierarchy?).

Yes, you can emulate them because Git is a general versioned, hierarchical key value store. But by the same token, you don't really need Git, you could just store each new version in a separate directory. A version control system is about more than providing raw access to a storage engine; it needs to support appropriate high-level operation and integration with the development process.

The problem here is the Procrustean way in which people try to force everything to fit Git's model rather than to think beyond its limitations (many of which are shared by other VCSes, I don't want to single Git out here) and to address these problems at the user experience level (especially when we're talking about normal users, such as writers and artists, who may not have a deep understanding of the technical details).

Post reply on HN