Hacker News Reader

Comment by angdis | Hacker News Reader

I think part of the problem is that git, like other version control systems, does not enforce any particular way of working (workflow).

When authors try to explain how to use git, they often have a very particular workflow in mind and don't necessarily describe exactly what that workflow is. This can cause major problems when somebody tries to apply advice to their own workflow.

I like the graphical approach. It helps to conceptualize what is going on so that someone can apply it to their own situation.

View on HN

That's not it. Following any reasonable workflow still requires a set of arcane commands and flags that only make the slightest bit of sense if you know how git is implemented. I was able to use SVN successfully without ever knowing a thing about the implementation. I've generally had the same experience with HG and even CVS and VSS back in the day. Git adds sophistication over a prodcut like SVN, but adds vastly more complexity.

Conversely, SVNs data model remained opaque after years of daily use simply because it solves the problem at hand poorly and is not defined very well.

I'm curious: did you use branches and labels in SVN? I've come across many svn repositories that don't use the trunk/branches/tags layout, and as a result the developers keep completely separate repositories for slightly different versions of their projects instead of creating branches. I've even seen new repositories created for each release version of the project.

If you're using svn you need to understand the implementation to get why copies are cheap, so that you can understand how to use branching and tagging appropriately.

The problem is that with SVN, you can get in gradually. To start, the branchless approach still gets you a great service - obviously an incomplete one, but better than not having source control at all. And you can have leaders who are the only people who have to think about branching and merging and have people very gradually move into that role.

Git seems to force you to dive straight into the deep-end, since everything is a branch, even your own local working folder.

Branches are fundamentally little more than text files in .git/refs/heads that contain the sha of a commit object. Don't let the idea of a branch frighten you, there isn't much complexity behind the idea.

Well, I know _that_ copies are cheap in svn, but I have no idea _why_. Yet I hope that I grok branches and tags.

I used SVN for years without understanding it and that caused me to get weird merge errors I never managed to figure out. Git on the other hand I understood after a few weeks of using it.

Since I failed to understand SVN after years of use I would say it is more complex.

That is where I am at. Being able to use something for years while never actually understanding it is not a desirable position to be in, and really does not equate to any meaningful sense of simplicity. It particularly is not something that developers should strive for in a system built for developers.

It's that its porcelain is a clusterfuck. The staging area is a hack that greatly convolutes the UI, and it would have been better if it were left out and you just had a way to cherry-pick what you want to commit at commit time (if it wasn't everything).

There's no symmetry in commands. The opposite of "git commit" is "git reset --soft HEAD^", not "git uncommit". "git reset" is three commands in one. I could go on and on.

git was designed as a data model and then a series of slapdash commands that enabled manipulation of that data model. It wasn't designed from the end-user perspective backwards, and this really, really shows.

I might not [EDIT: in fact, was not: see reply below] be appreciating the way that the staging area convolutes the UI for you, but you can pretend it doesn't exist by always just doing commit -a. And, if you want to "cherry-pick what you want to commit at commit time", well, that's what the staging area is for, isn't it?

Pretending it doesn't exist won't unconvolute the UI. I'm talking about things like "git checkout -- <file>", and "Git reset" which could just be one command if they didn't have to manage getting things in and out of the staging area.

I much prefer bzr's porcelain, it's much better designed and more sane.

You're basically railing against orthogonality. I don't think anybody disagrees that some flags could be made more consistent, but creating a separate git-uncommit when that functionality is fundamentally encompassed by the purpose of the third invocation of git-reset is a mistake.

If you make a specific case for 'git reset --hard/--soft HEAD^' then you would either be left without the more general (and more useful) 'git reset --hard/--soft <commit>', or you would have a situation where you have to use 'uncommit' to (for example) re-commit something, or you would be left with a git-uncommit command and still have git-reset for related operations. Why would any of that be better?

You could split the third invocation of git-reset off into its own command, but honestly I don't see the utility in doing that.

Disagree. A git-uncommit command tells you by its name what it's going to do, even if you know nothing about git or even if you don't know what a commit is, you can assume that git-uncommit will undo it.

git reset --hard tells you absolutely nothing obvious about what it's going to do unless you understand git and its specific incantations. You have to learn git commands, rather than intuit them.

git add -p

       -p, --patch
           Interactively choose hunks of patch between the index and the work
           tree and add them to the index. This gives the user a chance to
           review the difference before adding modified contents to the index.

           This effectively runs add --interactive, but bypasses the initial
           command menu and directly jumps to the patch subcommand. See
           “Interactive mode” for details.

I love the staging area, and I miss it everytime I have to us SVN at work.

I actually use the GIT-SVN bridge to work with git locally, pushing my changes up to SVN when I've resolved a topic. I do this in part because of the staging area. I have accidentally included changes in SVN commits so many times that I try to avoid SVN altogether.

I agree though, so many of the commands are just plain painful, the reset command(s) is a perfect example.

You have it right that it was designed as a data model. Linus has said a few times that it wasn't originally intended to be the Source Control Management tool itself, but more like a kit for building an SCM. Sadly, it took off so quickly simply because Linus built it and was adopted as the end user solution.

I have really mixed feelings about the index, personally. It is nice to be able to incrementally build up a change, but I do think that it's a thing that complicates learning for new users.

I'm curious, as someone who actually loves it, what if there were just better tools for incrementally altering the last commit instead? I'm not sure that a more robust git commit --amend couldn't achieve the same goals as the index with less conceptual overhead.

I had to use svn in college for some projects and we frequently ran into terrible merge problems that we simply couldn't figure out because we didn't know what was actually going on behind the scenes.

git is more complex on the surface, but I really find it to be so much simpler when you end up in real nontrivial use cases, especially when something goes wrong. I would agree that the commands are sometimes too memorization-intensive, but I've never been in a situation with git, even as a beginner, that I couldn't figure out and resolve relatively easily, especially with all the online resources available. I can't say the same for svn. Maybe I was just an idiot when using svn, but if I was an idiot there, I don't see why I wouldn't be an idiot with git as well unless there was just something fundamentally more useable and flexible and understandable about git.

The underlying data structures do matter, even with mercurial. One workflow I immensely appreciate with Git is locally committing some series of messy changesets and commit messages and then afterwards, when I have finished the feature, tidying everything up by rewriting the history (git rebase -i) before I push my commits.

When I tried the same approach with mercurial I found that rewriting the history is not reasonably supported by mercurial. They use these append-only data structures that sound nice, because they assure stability (no already written data is ever in danger because files are only appended) and fit with the general concept of commit->pull->merge. But when you want to change the commit history you clash with the append-only concept. The Histedit extension which is meant to provide this feature has warnings all over the place that what I do is dangerous and might result in data loss with changeset backups written to locations in the working tree. It's horrible compared to Git.

Now don't misunderstand me, Git has a lot of problems UI wise (for example I still don't really grasp what is going on with detached heads). But I find the fundamental design choices more sound than with any other VCS that I have tried.

Your rebase-based workflow is easily achievable with Mercurial. And there's even --outgoing switch in histedit.

> Histedit extension which is meant to provide this feature has warnings all over the place

Ignore them — you do know, what are you doing, right?

> changeset backups written to locations in the working tree

That's not true. Backups are written to .hg/strip-backup directory, which isn't tracked.

> Ignore them — you do know, what are you doing, right?

No, I don't :). I heavily rely on my CVS to never loose any data and to be able to go back to a previous state whenever I need to. This works great with Git's reflog.

> That's not true. Backups are written to .hg/strip-backup directory, which isn't tracked.

I stand corrected then. Maybe I'm mixing that up with amend or revert? I last used mercurial 9 months ago, but believe to remember there was some command that left .orig files lying around and that if you applied a history rewrite command several times those backups were overwritten with the new backups and you weren't able to come back all the way.

> to be able to go back to a previous state whenever I need to

as I've said, old commits are backed up.

> This works great with Git's reflog.

except git reflog is cleaned on git gc

Not mentioning http://mercurial.selenic.com/wiki/ChangesetEvolution feature is being in development.

> there was some command that left .orig files lying around

Only way .orig files may pop up is failure to replay rebased commit(s). No way these are backups — their purpose is to make user able to fix things and continue.

Reply on news.ycombinator.com