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

151–160 of 294 posts

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

#151

Post by cbcoutinho »

michaelgrafl wrote: post #147
yoodenvranx wrote: post #146

In the beginning I tried to use git exclusively through command line because I thought that's how real men do it. But after using gitkraken (or similar products) I will never go back to using git through its command line interface. Being able to see the whole repo structure is just so much more convenient and it helps to resolve most merging problems much faster. git guis all have their own problems, but overall usin…

I always have both open. Gitkraken for having a broad overview of local and remote branches, stashes, and for staging chunks of code. And the command line for everything else. Some things just confuse me in any GUI Frontend or don't work as fast as on the CLI.

This is what I do too. I like looking at my entire staging area commits using the CLI, but merging makes much more sense using GitKraken. Version control is just too complicated of a problem (for me) to reason about in one 'view', and using different tools to look at separate scales of a repository is the way I've found to work through that difficulty.

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

#153

Post by TickleSteve »

txdv wrote: post #67
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…

If you consider the use case "linux kernel development", you realize that you really don't want to automatically commit all your changes.

...and why is kernel development any different to any other large scale project?

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

#154

Post by bloodorange »

majewsky wrote: post #102
__david__ wrote: post #68

Earlier quoted context omitted.

Sometimes I find myself doing "git stash; git stash apply" just so I have a checkpoint of what I'm working on. That plus "git stash list -p" lets me go back through tons of non-checked in junk to find (say) that one line of debugging code that turned out to be pretty useful…

You can do small temporary commits on a branch, and once you want to do an actual commit which will then be pushed, you go onto the master branch and `git merge --squash `.

This.

Git makes using branches very easy and it is fairly quick with most operations. Once you understand what the commands are doing, you'll see that unless you do something specifically (like reset --hard with uncommitted changes, checkout a modified file etc.), you'll never lose work which has been committed in some branch or the other.

I tend to just do "in-between" commits very often and rebase to reorganise the commits (reorder, squash, reword) when I hit a (micro)milestone.

If your work has been committed and the repo was not just garbage collected, it is going to be easy to retrieve it from reflog even if you did something nasty with the branch and it appears that your commit has disappeared.

Git is the piece of software which I find very good in terms of what it does but it does it behind the worst user-interface I have ever encountered.

EDIT: minor clarifications and punctuation

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

#155

Post by ryanbrunner »

icebraining wrote: post #97
jcranmer wrote: post #53

Earlier quoted context omitted.

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.

The authour of this article suggests a solution - `git commit --interactive` could prompt you for each change like `git add -p` does without needing a staging error. You're right though that it would take some cleverness in that command to allow you to fix a typo without restarting the operation.

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

#156

Post by tomxor »

I like what this guy has to say so far, but it's a bit surprising that someone with his knowledge got this wrong:

> 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

I dislike the mess of crappy synonyms too, but git diff --staged is already an alias, in fact it's the primary way I diff the staging area because it's a well fitting synonym.

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

#157

Post by nhaehnle »

rbehrends wrote: post #109
nhaehnle wrote: post #85

Earlier quoted context omitted.

As a convinced Git user, this is the one aspect of the article that I found genuinely interesting. I mean, you can commit anywhere in Git, too (and I occasionally do for some advanced use cases), but it tends to not be well supported by Git. (And, I might add, probably not by Hg either if it requires enabling an extension...) Anyway, hg show work looks like an interesting thing. It's perhaps a bit more magic than Git…

> As a convinced Git user, this is the one aspect of the article that I found genuinely interesting. I mean, you can commit anywhere in Git, too (and I occasionally do for some advanced use cases), but it tends to not be well supported by Git. "Not well supported" in this context means that you can lose data (as commits that are not reachable from a ref can be garbage collected). Mind you, you have to ignore warnings…

It is supported, it's just that the only thing keeping commits not on a branch alive is the reflog.

Question: How does Mercurial deal with garbage collection? After all, the desire for garbage collection is by far not unique to Git -- any version control system that has the equivalent of `commit --amend` and rebase should provide it.

As for not needing the extension, it seems to me that having "dangling" commits would be very difficult to use without some decent visualization of the dangling commits, such as what the blog post shows with `hg show`.

> It's probably also worth noting that we have an implementation detail leaking into user space here.

I find this comment absolutely fascinating, because truly, this is not an implementation detail leak at all.

The point of the purely functional data structures isn't to achieve atomicity (although potentially being a bit more robust to power loss etc. is certainly a nice side effect), it's a way of thinking about version control. I've never heard functional programmers use atomicity as the main argument for immutable data structures, either...

The whole point of Git's design is that it chose a robust and crystal clear way of thinking about distributed versioning as its underlying model of what version control is, and then simply provided tools for manipulating that DAG. Some of those are a bit ugly because of how the system grew over time, but still, this is how software should be designed: have a clear model of what the data is, then provide tools for manipulating it.

For what it's worth, the underlying data store of Git could quite easily support "unnamed" tip commits as well. What you'd need is a change in the garbage collection policy, and "porcelain". Which brings me back to the question of how Mercurial does it.

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

#158

Post by tomxor »

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'd like to think I know git pretty well... I understand the internals, i've written cli tools that utilise all the plumbing commands, I understand the different types of objects merkel trees, and various form of references.

Yet, once when I had a power failure by chance the second I fired the commit trigger... I was pretty hopeless at trying to clear up the mess of objects it exploded everywhere, I couldn't be bothered and just re-cloned the blasted thing, hope it never happens to me again.

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

#159

Post by bauerd »

yoodenvranx wrote: post #146

In the beginning I tried to use git exclusively through command line because I thought that's how real men do it. But after using gitkraken (or similar products) I will never go back to using git through its command line interface. Being able to see the whole repo structure is just so much more convenient and it helps to resolve most merging problems much faster. git guis all have their own problems, but overall usin…

First time I hear of gitkraken but why would a Git repository viewer have me create an account!?

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

#160

Post by larsbrinkhoff »

jhanschoo wrote: post #135
qznc wrote: post #116

Earlier quoted context omitted.

> 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.

I have used git a lot, and rarely, if ever, get it into a confused state. I have used Mercurial less, and I have found it easy to get things tangled up without a clear way out.

It kinda sounds like the system you know best, is the one you can handle better regardless of whether it's git or Mercurial.

Post reply on HN