Comment by trustfundbaby | Hacker News Reader

Comment by trustfundbaby | Hacker News Reader

Parent Full thread

> A big problem with git is that the commits-and-branching model is poorly thought through

Really? I think that is one of its strongest points. being able to switch branches by just going 'git checkout <branch>' and immediately having the entire file structure switched out to what's 'contained' in the new branch was a big win for me.

Git also alerts you when you've made changes and are switching branches, so you can commit or stash your changes to the branch you were on and not mix it up with the new branch, unless thats what you really want to do.

> It's very easy to find yourself on no branch at all

Interesting. In what situation would that happen? I always thought you had to be on some sort of branch (master) at least to use git.

> It's merging workflow is awful - I'm fine with correcting the odd whitespace-as-conflict, but I find the fact that git presents me with >>>>> eyebiting ====== conflict markers <<<<<< even when I'm using a merge tool difficult to excuse.

Sounds like we're complaing about a cosmetic issue.

> Frankly, I see two kinds of arguments in support of git:

How about the fact that its branching model is pretty awesome and it gives you the tools to do exactly what you want with your version control (rebase, amending commit histories etc)?

"Really? I think that is one of its strongest points. being able to switch branches by just going 'git checkout <branch>' and immediately having the entire file structure switched out to what's 'contained' in the new branch was a big win for me. Git also alerts you when you've made changes and are switching branches, so you can commit or stash your changes to the branch you were on and not mix it up with the new branch, unless thats what you really want to do."

Cheap branching is a fantastic feature - that all the open DVCS tools have.

Git focuses on the ability of developers to edit their revision history and provide lovely linear histories (hence the existence of stash, rebase, et al). Git as a tool and as a community encourages one to do so - but the result can be that your local repo and my local repo can no longer be synchronized. Furthermore, it's easy to create a commit of inconsistent code - since you can commit file changes in separate commits.

Ultimately git simplifies the work of project maintainers at the expense of day-to-day development, which isn't surprising given it's source, but I think it's a bad trade.

> Furthermore, it's easy to create a commit of inconsistent code - since you can commit file changes in separate commits.

Actually, that's a feature. You can make finer grained commits this way. Use rebasing (or amending a commit, when you are just putting in the second commit) to make your changes atomic, when they need to be atomic.

Your repository isn't always in a consistent state. There's value in keeping inconsistent in between states---and git allows you to do that, but also allows you to clean up, after you're finished.

(Of course this creates an alternate history.)

the result can be that your local repo and my local repo can no longer be synchronized

Nope. All rebase operations create a brand new branch and merely repoint a ref at it. The original pre-rebase branch is still untouched, and "git reset HEAD@{0}" (see: git-reflog) will reverse the effects of any rebase (and of course, you can undo the undo). Rebase does not affect synchronization in any way except that two users may have very different commit histories that they both call "master". Git handles the synchronization fine, however, so this is a social issue rather than a technical issue. I regularly work on large projects with many committers that rebase, and I have never had any difficulty. Hell, git pull even defaults to "git pull --rebase" now, so you probably won't even see any merge commits when you pull from someone's rebased branch now.

Ultimately git simplifies the work of project maintainers at the expense of day-to-day development

I disagree again. Git makes both day-to-day work easy, and it makes maintaining the project easy. When you are in hacking mode, you just commit with a short message whenever you feel like it. Commit freely, branch freely, merge freely, undo freely. When you are done and you want to cleanup your work to share, you can quickly split commits, combine commits, reorder commits, add better commit messages, and so on. Then, you can push to a public repository, ask someone to pull your branch, or just email patches around. If you mess it up somewhere, everything is undoable. Git even has tools to make merge conflicts easy to handle; if it sees a conflict you've manually repaired before, it can automatically try that repair without bothering you again.

Anyway, it's clear that some people take issue with people "rewriting history" and that they will never use git. But I take issue with having to maintain projects that have an incomprehensible (but "historically accurate" in the sense that I know exactly what the state was when some random person on the Internet typed "commit") history, and so I use git. It is the most efficient use of my time and mental energy, and is why its become so popular.

>> It's very easy to find yourself on no branch at all > Interesting. In what situation would that happen? I always thought you had to be on some sort of branch (master) at least to use git.

If you check out a revision, and not a branch, you will be on "no branch at all". But you asked for it, then.

And of course, you can still commit there and give it a name later. Hack, then cleanup. That's the git model.

Just don't do a GC, while you have dangling commits.

You're fine as long as the detached head is newer than two weeks old. (And you might be fine past that point. While the branch is "unnamed" it does have a ref in the reflog pointing at it.)

I figured this out eventually. However, when I first switched to git (and before I had tools to show my branch in my prompt), I managed more than once to make 3-4 commits on a detached head, and finding out how to fix that between the documentation and/or Google was essentially impossible. Once I simply gave up and re-did the work. The other time I figured out how to fix it, at the cost of about 3 hours of research and (eventually) questions on the IRC channel.

It's a powerful tool, and the docs are fine if you are an expert who already knows what you're looking for. I'll submit that it can be incredibly hard for a noob to learn to use correctly.

Reply on news.ycombinator.com