Hacker News Reader

Comment by ngoldbaum | Hacker News Reader

Mercurial gets around this issue (without having a staging area) by providing an interface for interactively committing files or subsets of files via "hg commit --interactive"

View on HN

The staging area is a lot more useful than what you can do with an interactive commit, since it persists between operations. You can use it to accumulate changes that are "done" while you continue to experiment with some other changes on top, even if you're planning on committing the whole thing at once, and if you wind up not liking your new changes, revert to what you had in the staging area; or you can realize what you're working on will be easier to finish as two commits, stage part of it, stash the other part, finish the part that was staged and commit it, then apply the stashed part and finish that too.

This is a lot more than you get with just a single interactive commit operation.

You could use a commit for this purpose, and continually amend or revert this commit, but in terms of UI, it's helpful to have a set of operations specifically for moving things in and out of the staging area that's different than what you do for manipulating commits on general.

The whole problem with the staging area in git is that it persists between operations.

Why would you want to add things piece by piece and not commit them? If they are done enough to be added they are done enough to be committed and if they are not you keep working on them together with all other unfinished files. Once you actually are ready to commit you can choose which files that are in fact ready.

> Why would you want to add things piece by piece and not commit them?

It provides useful checkpointing, so in practice I find that there are lots of things that I will add to the index even though I am going to keep working on them. Committing these intermediate changes is annoying because it just creates extra work when I make the final (squashed) commit.

This strikes me as one of those disagreements that simplifies to, "That's not how I do things, that's horrible."

The other half to this is that commonly, during an interactive commit (git add -p or hg commit --interactive), I realize that I missed some small change. Being able to persist that state means I can add the small change without redoing the interactive commit.

Surely some experienced people would want to do it this way and im not against providing an option to do so. The problem is that it's required and the names of the commands are totally misleading for beginners. "add" sounds like something you do the first time you add a file to the repository, not something you have to do every time you modify it. Don't even get me started on umstaging files: git reset which sounds like an extremely dangerous operation when all it does is unstage files, except if you pass it some flags then you can really loose data.

How is it helpful to have more concepts and commands that simply duplicate advanced functionality and have to be used every time complicating even the simplest cases? As you said it can all be done with amend and other normal and optional commands already.

Or you can use an easy-to-use but powerful UI like TortoiseHG, where it's trivial to check files or hunks for commit, stash (shelve), amend, revert, rebase, ...

TortoiseHG with hggit is the best git client.

And that's before even mentioning the best parts like phases and obsolescence markers.

> and have to be used every time complicating even the simplest cases

Take a look at `git commit -a`. I sometimes teach this one to beginners if I feel that the idea of staging is confusing them.

Git has the same with `git add -p`, and if you're operating on a gui system, git-gui is excellent.

I did not know that existed. Thank you for informing me.

There is also a very nice curses interface for interactive chunk selection. To turn it on set interface.chunkselector=curses under the ui section in your .hgrc.

Reply on news.ycombinator.com