Hacker News Reader

Comment by ripa | Hacker News Reader

What is the argument against having a staging area? The Git staging area is crucial in my mind.

It's simply not necessary to have that feature. Sapling encourages regularly committing and amending commits rather than staging changes.

It's also easy to commit / amend part of your work by selecting the lines to include in nice curses interface (--interactive).

I guess each to their own. I want to stage my commit with regular commands, and then have the staging area work with (diff, add/remove etc).

I don't care for an interactive tool, IMHO I prefer using commands that are repeatable and learnable instead of stepping through some interactive workflow all the time.

I agree it's not necessary, but i like having it because it lets me separate what's going to be added before i actually commit.

I still commit small, frequent. But i like `git add -p` to skip debug lines, hardcoded conditions, etc. I don't want to mistakenly auto commit a whole pile of lines and then have to remove debugs/hacks/etc from things i've committed.

Stage + Unstaged is my working area, and the two live together quite nicely to me personally. I could live without it, definitely.. but i'm not sure i'd want to.

In those cases, I find it best to either 1) use the interactive commit tool to not commit debug junk, or 2) put the debug junk in its own commit, which I'll later discard (and, plus, that means you can't accidentally include it in a real commit).

I’ve never used one of the source control systems at these big companies but I use the staging area along with your git-branchless just fine for now. I’m not sure if it’s any less efficient this way.

It's not a big deal either way, but the staging area interacts worse with some operations. For example, if you have staged changes and then get a conflict with `git checkout --merge`, AFAIK there's no way to undo to before the conflict in Git. When using commits, all of the standard merge and undo tactics apply.

> Stage + Unstaged is my working area, and the two live together quite nicely to me personally. I could live without it, definitely.. but i'm not sure i'd want to.

You can just use the tip as your staging. Use interactive amending to move changes from the working copy to the commit, and when you want to "commit", finish up the message.

hg actually has an "unamend" command (part of the "uncommit" standard extension) which... reverts the last amend. Rather than having to remember how to contort reset into the right shape to move changes back out of staging without destroying everything.

`git reset HEAD~` doesn't feel like that much of a contortion to me. It's the destructive change that requires more contortion (`--hard`) which feels fair. Maybe this is stockholm syndrome though.

The way I think of it, there's basically three copies of the file in play: in HEAD, in staging area, and on disk. I cannot trust my memory to remember which variant of "git reset" copies the file in HEAD to the staging area, which variant copies staging area to disk, and which variant copies HEAD to disk (in all cases, the third copy remains uninvolved). Getting it wrong potentially creates unrecoverable data loss. And, unfortunately, this is one of those cases where reading git's documentation is less than helpful.

Combine this with the case where "I want to break one commit into two commits," where now I have to worry about making sure I know if the command is going to change the revision HEAD points to. At least there, the old commit will still exist as backup in the invariable scenario I screw something up.

> But i like `git add -p` to skip debug lines, hardcoded conditions, etc

You can use `git commit -p` to get the same functionality but without explicitly using the staging area.

How do you construct a commit, in order to commit regularly, without having a staging environment in which to compose that commit?

Is the branch-tip simply the staging area? What if you're only half-done with that final commit?

You `sl commit` that half-done work anyway and then iterate by running `sl amend` many times until your commit is finished. In case you want to amend just part of changes us `sl amend -i`

https://sapling-scm.com/docs/commands/amend

> How do you construct a commit, in order to commit regularly, without having a staging environment in which to compose that commit?

In git, with `git commit --patch`

It stems from the original Mercurial implementation. The goal here is that every operation leaves the repository in a good state that can be pushed/pulled. That's why Mercurial and Sapling rely on commit/amend/uncommit, etc and for example usually discourage the use of interactive rebasing in favor of restack and other operations that add another "state". It facilitates the mental model for developers without actually removing workflows (they are just different).

As I understand it restacking is rebasing no?

Yup, it's automatic rebase of a commit on top of the newer (amended) version of its parent.

Reply on news.ycombinator.com