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

71–80 of 294 posts

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

#71

Post by scotty79 »

klodolph wrote: post #25
Klathmon wrote: post #17

Earlier quoted context omitted.

> 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 langu…

That's not really a "better VCS" that's just a better 3-way merge. You can already plug your own 3-way merge into Git and other VCS.

Can you recommend any language aware 3-way merge tools?

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

#72

Post by Dylan16807 »

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…

> Edit: the model I adapted to from my hg workflows is effectively commit --amend. Mercurial has an interesting way of doing history tracking such that if I really need to, I can actually follow the history of the "oops, I need to change these commit because I missed a compiler failure" or "I forgot to save this file before committing," which is a feature that git doesn't have. If you promoted amending the last commit, you wouldn't need a staging area to build up a commit, the last commit does it for you already.

I'm confused about what you think --amend is lacking. If you want a full history including amendments, why not make real commits? In case you need it git can track the original edit-showing history of something too, it's just awkward. Do you think more people would use it if it was easy?

Also if you really want to uncommit and restage it's a simple command to write down. (reset --soft HEAD^)

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

#73

Post by __david__ »

bringtheaction wrote: post #49
rzzzt wrote: post #47

Earlier quoted context omitted.

Stashes should cover your first scenario; put those changes (both staged and unstaged, optionally also untracked files) in a bag and re-apply them when you are back from your short expedition: https://git-scm.com/docs/git-stash To clean up outgoing changes, you can run an interactive rebase of the current branch onto its remote tracking counterpart. This will list all affected commits in a text editor, and allows you…

Problem with stashing is that you then need to redo the work of staging afterward.

Stashing saves/restores the staging area so you shouldn't need to redo anything.

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

#74

Post by nhaehnle »

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…

I think people generally get side-tracked by focusing too much on the staging area. It's a red herring in my opinion. I barely notice that it's there, and I do the crafting-the-public-changelog thing on an almost daily basis.

I recommend learning about the combination of `git gui` (including its amend option), `git rebase -i`, and `git commit --squash=/--fixup=` (and don't forget to set `git config --global rebase.autosquash true`).

The workflow in Git could still be improved: `git gui` should really allow you to create "squash!" commits more comfortably, for example (I often end up staging with `git gui` and committing on the command-line).

Also, it would be awesome to have an editor in which you could make edits to selected commits directly in a rebase-like fashion. But I don't think that exists for any version control system out there, and getting the UI right for dealing with conflicts would be quite challenging.

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

#75

Post by uiri »

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…

Often I'll work on a large change and make sure that it is working before I start crafting my commits. By the time I get to that point, I realize that I've actually made three separate subchanges so I do partial stages to create each commit.

I use git status -s and git diff quite a bit as a sanity check (for things like whitespace) and to do first party code review before I send anything out.

The staging area is a core part of my personal git workflow pre-commit. It seems to be producing good results so far.

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

#76

Post by scotty79 »

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 think in feature branching workflow it would be more useful for the branch to have a message not the commit. Commit is way too small of a unit to be meaningful more often than not.

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

#77

Post by ygra »

scotty79 wrote: post #71
klodolph wrote: post #25

Earlier quoted context omitted.

That's not really a "better VCS" that's just a better 3-way merge. You can already plug your own 3-way merge into Git and other VCS.

Can you recommend any language aware 3-way merge tools?

Semantic Merge comes to mind, although it only does an AST merge on the structural level while blocks are still merged traditionally (I guess it's a good tradeoff of complexity, though). It has however proven to be rather slow with large merges (or large files; the source file I tried to merge had ~4 kLOC), in my recent test (was merging a major version of one product into derived ones, with lots of refactoring, so I thought SM could help).

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

#78

Post by gmueckl »

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.

So you disagree based on your personal experience? That is fine. I base my observation on what the people around me were using in various environments, so I am actually fairly confident that this can be generalized. This is the best I can do unless someone makes some representative statistics over a broad user base.

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

#79

Post by yeukhon »

Here are the commands I use:

git init

git clone

git checkout

git commit

git commit -m

git commit —amend

git rebase

git add/rm/diff [—cached]

git push

git branch

and a few more I can’t remember exactly.

I try to keep my git workflow simple. The most complex is probably checkout abd rebase with several different branches.

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

#80

Post by lucideer »

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…

If this is the "correct" way to learn, the problems are not with the user.

A well designed ui should be learnable while being used - creating a fresh learning repo for dedicated learning for fear of losing data while using the tool in your "real" repo is the ultimate red flag in terms of usability.

Post reply on HN