[ripa]

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

[mitrandir77]

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).

[lijogdfljk]

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.

[ripa]

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.

[ISL]

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?

[somnium_sn]

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).

[IshKebab]

As I understand it restacking is rebasing no?