Hacker News Reader

Comment by norswap | Hacker News Reader

From the video, it looks like all changes are automatically staged. Ignoring the staging area is not going help users understand git I think.

Otherwise, it looks very very cool.

View on HN

Agreed; the ability to commit a subset of the changes in your working directory makes it far easier to make a large number of small, focused, single-change commits. Tools like "git add -p" make that even easier.

If you ignore the staging area, you become much more tempted to make several unrelated changes in one commit, rather than untangling them.

I agree.

The git UI has some warts, but the staging area isn't one of them. It's an extremely useful feature, and a true improvement over traditional SCM interfaces.

It's nice to see people wanting to improve git's interface, but please, don't just dumb it down....

The staging area doesn't really help much with that, though. Too often there are unrelated changes to the same file, which are precisely as inconvenient to split up as those in separate files without a staging area.

The staging area makes it possible to split them up by selectively adding lines to it with `git add -p` or the much superior `git gui`.

That's exactly what git add -p does, and it's vastly more convenient than when you don't have a staging area.

I find the problem with git add -p is when you have changes that are overlapping - e.g. you've tried a few variations of implementing something, that have many commonalities - but sadly you didn't commit them as you went along, but now what to, for reference in case they are needed later.

git add -p doesn't help tease them apart, because its hunks are based on diffs, and the granularity usually does not coincide with actual changes (nor syntax or semantics of the languages). Which is really expecting a bit too much! Diff's implementation of LCS algorithm is incredibly fast and works amazingly well for changes in different places.

So what I do is edit the file to what I want, stage and commit, then undo and continue. This doesn't really use the staging area, and I'm hoping there's a better way to do it... if anyone can think of one?

I don't use `git add -p` much, since i commit exclusively with `git gui`. The reason being that `git gui` allows me to stage single lines, or hunks AND allows me to change the granularity of hunks on the fly. Even if that isn't an option for you, i'm sure that `git add -p` has a command to modify hunk granilarity.

git add -p, then "s" until it can't split the hunk any more, then "e" to edit the hunk manually?

you can do it, but I've found in some cases that modifying patches (including "e") becomes more complex than stating the desired result directly.

One thing that I've found handy on a few occasions is Atlassian Source Tree. You can stage individual lines, not just individual hunks. Sometimes that makes it much easier to pull apart the changes.

I actually started of having the staging area use git add etc. and being just a reflection of what was staged. But that meant I either had to manually add each file (or have an "add all" button), or automatically stage them. The first option felt wrong because most of the time you just want to commit all the changes, so in most cases it's just more work for the user. The second option felt wrong because I didn't want to change around the git structure "behind your back" (just starting ungit shouldn't mess up your repo); so I went with just having it in the ui and doing the real git work on commit. In general I want it to be as close to git as possible but I hope this trade off made sense with this little explanation :)

In the small scale your rationalization is logical, however in the big picture you're going to end up with teaching people to make useless commits. As long as this is true of ungit, it is a project i will have to vehemently recommend against in any circumstance.

What ungit should do is the same thing as git gui: When you go to make a commit, you can view diffs of your files and select single lines to be added to your next commit.

Edit: I've created an issue for this: https://github.com/FredrikNoren/ungit/issues/98

I think the staging area is a horrible idea. It greatly complicates the UI ("diff --cached"? Really?) without providing many benefits (if you want to commit just some files, you could simply specify the names at commit time.

I really love bzr's UI in this respect, and I understand Mercurial is similar too.

You could use git commit -a, but I've found that seldom does what you want. Usually, you don't want to commit all files, because you've made unrelated changes to configuration, debug logging etc. And sometimes you don't even want to commit all the changes in a single file, and git lets you choose which diff sections ("hunks") to commit with git add -p.

I came to git already knowing what a dag was, and after having cobbled together my own patch management system to make up for deficiencies in svn, so I didn't have much difficulty intuiting almost the whole of git after very little time.

I came to git from bzr, and I always use commit -a these days. If I want to ignore a file, I just specify the ones I actually want to commit, and it works just fine for my purposes (I don't generally make irrelevant changes).

YMMV, of course.

You couldn't run tests only on your staged changes pre-commit without the staging area. Right now my pre-commit hook stashes any non-staged changes, from inside the same files that has staged content, and then runs tests. This ensures I can create commits with just the stuff that works of my changes without first removing the ongoing work.

The staging area surely adds complexity, but if you do not like it then simply don't use git.

> This ensures I can create commits with just the stuff that works of my changes without first removing the ongoing work.

If I have ongoing work I want to remove, I just stash it, as you said. I don't need a staging area to stash things, and it's pretty rare that I'll have unrelated work anyway.

> The staging area surely adds complexity, but if you do not like it then simply don't use git.

Ah, the old "your arm hurts? Just cut it off!" solution. Yes, I will just not use git, I will just email my team diffs.

If you are using a recent git version, you can use diff --staged instead - diff --cached is there for existing users.

Specifying names at commit time is really horrible - it's more error prone and harder to get a diff of exactly what you are committing.

You can also commit part of files using the staging area by doing git add -p. My workflow is often git add -p; git diff --staged; git commit

And, alternatively, you can use `git commit -a` if you want to bypass the staging area.

I am avoiding git's CLI like the plague, but IMHO the staging area is awesome to use with a GUI like Git Tower - it was never that easy to stage (and commit) line by line, leaving out stuff like printf debugging that shouldn't go down the wire.

Then again, I guess the GUI could just implement the staging area itself and pass line numbers to "git commit" :)

Yes, exactly. Atlassian's client (I forget the name) has that feature too, and it's great, but it can just do it directly if there's no staging area (as it does with hg, I assume). If you're in the CLI, you can use the exact same command you use to stage stuff to commit stuff, and then there's exactly zero benefit.

I spent a depressingly long time using git before understanding how the staging area worked.

I think hiding it under a novice/expert flag is a terribad idea, but I'm not sure what the right way to expose the staging area in this interface would be.

Not at all -- you can uncheck some files, and only the checked ones will be committed.

Reply on news.ycombinator.com