Coming from someone who learned hg well before git, and who's now being more or less forced to use git long after developing comfortable hg workflows, the staging area feels like a half-baked implementation of what it's supposed to be doing.

I'm used to thinking of commits as atomic commits--roughly, each commit is the smallest change that atomically makes sense. So you should be able to use the staging area to build up that commit as you find more pieces to make it in. But while I'm slowly hacking away at this commit, I talked with someone else and decided to try an idea which turns out to be a small commit. But I've already got this half-built-up commit that's staged, so I need to commit that to make the new commit, and then somehow reverse the patches and restage the commit (which is something that's well outside my git comfort level).

What hg has is a few different features that make it possible to build up not just a single commit but an entire commit sequence and do operations on that commit sequence (like reorder them). The git staging area is kind of a weak version of that, but it ends up being in limbo: too complex for the simple just-commit-everything model but too simple for try-to-craft-the-public-changelog model.

Edit: the model I adapted to from my hg workflows is effectively commit --amend. Mercurial has an interesting way of doing history tracking such that if I really need to, I can actually follow the history of the "oops, I need to change these commit because I missed a compiler failure" or "I forgot to save this file before committing," which is a feature that git doesn't have. If you promoted amending the last commit, you wouldn't need a staging area to build up a commit, the last commit does it for you already.

Some useful commands I'd use in scenarios like this are:

  git add -p # select what to add to the staging area
  git reset -p # deselect chunks that I decided I don't want anymore
  git stash # saves your working state in a temporary commit (not in your branch)
  git stash pop # restores the working state from the last git stash command and drops the temporary commit
  git rebase -i $start_point # where $start_point is either a branch or some commit in your branch history. -i means interactive, which allows you to reorder/edit/reword/squash commits
  git checkout -b $newbranch $start_point # you can make a new branch at any commit in history, so if you decide to reorder your commits, then declare and older commit as a branch and get it merged first, that's fine. $start_point is optional, if unspecified the current HEAD commit is used.

For your specific example, with a staged partial commit on branch idea-1, I would:

  git commit -m 'WIP idea 1'
  git checkout -b idea-2 HEAD~1 # makes a new branch at the parent of the HEAD commit
  git add -p # pull in the desired changes
  git commit -m 'idea2 implementation'
  git checkout idea-1
  git add -p # stage the rest of the changes
  git commit --amend
  git rebase idea2 # if idea 1 depends on idea 2

I do wish git had some notion of sub-commits with their own messages, and a better UX for cleaning up a set of commits before merging them.

> I do wish git had some notion of sub-commits with their own messages

You could use the "fast-forward with merge commit" style. [1] Then you can treat the commits from the branch as sub-commits, and the merge commit as the parent commit.

[1]: https://stackoverflow.com/questions/15631890/how-to-achieve-...

Interesting! That's almost what I want, except here's the specific behavior I want to achieve:

  A clean git log view that shows only meta-commits
  Git blame shows both the meta-commit and the sub-commit for each line

I suppose I could get creative by enforcing that tags be embedded in commit messages and then filtering them in the log view, but it would be better if it was standard.

You can show only merge commits with

    git log --merges

However, I don't know if there's any way to achieve that with git blame, and not all tools may offer that kind of log view.

> I do wish git had some notion of sub-commits with their own messages, and a better UX for cleaning up a set of commits before merging them.

Does rebase -i handle this adequately or am I misunderstanding what you're describing here? My workflow sounds like exactly what you're saying here, where "subcommits" are my development commits and the UX is the rebase -i editor.

See my reply to mmebane about sub-commits. Re: UX, specifically the patch editor (git add/reset -p) is sometimes difficult to use. For example, I've had issues with changes that happen around empty lines refusing to apply for unknown reasons.

With git, you can stage line by line, file by file. You don’t need to commit everything at once. Also, you can add the lines you want in to staging, then use the stash feature to temporarily save lines that you don’t want in the commit. This allow you to test the commit without all of the extra lines you don’t want.

I would highly suggest reading Pro Git [0], a well written book on not only how to use git, but also the best practices, common workflows, and some of the internals in to how git works. Many refer to it as the essential book on git.

[0]: https://git-scm.com/book/en/v2

I don't know mercurial, and I agree about the limitation you mention for stashing the index. That said if I need to do a refactoring or something else while I have an unclean tree, I stash before doing it, then commit it, and then unstash my work.

> What hg has is a few different features that make it possible to build up not just a single commit but an entire commit sequence and do operations on that commit sequence (like reorder them).

Again, I've never used hg (beyond a simple tutorial), but you can commit frequently with git (every few other changes "WIP") and reorder / fuse / edit later through interactive rebase.

I think people generally get side-tracked by focusing too much on the staging area. It's a red herring in my opinion. I barely notice that it's there, and I do the crafting-the-public-changelog thing on an almost daily basis.

I recommend learning about the combination of `git gui` (including its amend option), `git rebase -i`, and `git commit --squash=/--fixup=` (and don't forget to set `git config --global rebase.autosquash true`).

The workflow in Git could still be improved: `git gui` should really allow you to create "squash!" commits more comfortably, for example (I often end up staging with `git gui` and committing on the command-line).

Also, it would be awesome to have an editor in which you could make edits to selected commits directly in a rebase-like fashion. But I don't think that exists for any version control system out there, and getting the UI right for dealing with conflicts would be quite challenging.

Resorting to rebase is a pretty heavy price to pay though.

From my experience, there's no such a heavy price as long as you don't rebase what you already shared with others.

How so? It's very fast and you can abort if you do it wrong.

Well, the obvious and immediately painful one is the hard-to-recover failure mode when you discover something you rebased wasn't private after all. (Which can happen in many situations, eg github merge button, even without other people involved).

The other is that it destroys history, you change the record of what actually happened to the version that is a plausible simplification in the opinion of git's diff/merge heuristic. You then can't then go back for to look for explanations of bugs or test code changes, which change happened first or whether a fact claimed by a commit message was really true at the time, or where is some change a merge mess-up or considered change.

Rebase also really complicates the mental model of git you have to work with.

I appreciate though, that there are cases where you want to withhold the record of what actually happened and use squash/rebase, it's a type of privacy from others. But simply grouping together commits into one is not a good reason to do it, that's what merge commits are for after all.

> Well, the obvious and immediately painful one is the hard-to-recover failure mode when you discover something you rebased wasn't private after all.

How is this hard to recover? You have full control of both copies, the system protects you against data loss, and you can easily pick one of the two, rebase one against the other, etc. to recover.

> Which can happen in many situations, eg github merge button, even without other people involved

This is the real problem and it's DVCS agnostic. If you make a bunch of changes to the same code without staying current, a human is going to have to reconcile it. If you follow recommended practice and update your local changes against the shared upstream regularly, this is a far more manageable problem — and that's true for every version control system in existence.

> The other is that it destroys history, you change the record of what actually happened to the version that is a plausible simplification in the opinion of git's diff/merge heuristic.

More correctly, you change it to the version as presented by the human who made the decision to rebase. If someone chooses to remove important context you can have problems but that's the same category of social problem you'd have with someone who uses poor commit messages, makes commits which are incomplete, etc.

> Rebase also really complicates the mental model of git you have to work with.

I find the opposite to be true. Most of the people I've taught seem to quickly grasp the idea that a rebase is simply taking your set of changes and moving them to apply against the current shared consensus rather than that state when you started, whereas merges cause regular confusion during code review or conflicts when people are asked to reason about changes someone else made.

Stashes should cover your first scenario; put those changes (both staged and unstaged, optionally also untracked files) in a bag and re-apply them when you are back from your short expedition: https://git-scm.com/docs/git-stash

To clean up outgoing changes, you can run an interactive rebase of the current branch onto its remote tracking counterpart. This will list all affected commits in a text editor, and allows you to reorder, squash, change the commit message or the content, much like how you describe it works in hg: https://git-scm.com/docs/git-rebase#_interactive_mode

Problem with stashing is that you then need to redo the work of staging afterward.

You only need to git stash pop and the staging area is back as it where, there is no need to redo the work of staging.

you can --keep-index to avoid stashing it, and then make an additional stash. If you have modifications within the same file it'll complain about conflicts though, so on the second sash you'll have to `git stash show -p | git apply -R` and then drop the stash, which is super clunky.

Stashing saves/restores the staging area so you shouldn't need to redo anything.

> Edit: the model I adapted to from my hg workflows is effectively commit --amend. Mercurial has an interesting way of doing history tracking such that if I really need to, I can actually follow the history of the "oops, I need to change these commit because I missed a compiler failure" or "I forgot to save this file before committing," which is a feature that git doesn't have. If you promoted amending the last commit, you wouldn't need a staging area to build up a commit, the last commit does it for you already.

I'm confused about what you think --amend is lacking. If you want a full history including amendments, why not make real commits? In case you need it git can track the original edit-showing history of something too, it's just awkward. Do you think more people would use it if it was easy?

Also if you really want to uncommit and restage it's a simple command to write down. (reset --soft HEAD^)

The staging area is trivial to use effectively.

Just:

- edit files - git add -e - optionally git diff --staged (to review what will go in a commit) - optionally lather, rinse, repeat as needed - git commit

Alternatively:

- edit files - git add - git commit - lather, rinse, repeat - git rebase -i origin/master (or whatever) and reorder/squash/edit/split commits as needed

For the latter's last step, sometimes the easiest thing to do is to squash all commits when you're done, then git reset HEAD^, then apply the git add -e && git commit loop in order to break up your work into logical commits.

When done, push.

> But while I'm slowly hacking away at this commit, I talked with someone else and decided to try an idea which turns out to be a small commit. But I've already got this half-built-up commit that's staged, so I need to commit that to make the new commit, and then somehow reverse the patches and restage the commit (which is something that's well outside my git comfort level).

Git stash

> What hg has is a few different features that make it possible to build up not just a single commit but an entire commit sequence and do operations on that commit sequence (like reorder them). The git staging area is kind of a weak version of that...

The git way is to make a new branch and then use git rebase -i

You should look up the stash command.

Partial commits through piecemeal staging is great as a poweruser's tool, like rebase. But it's beyond weird that anyone thought it was a good idea to make people deal with staging for every commit.

It doesn't even have to go away. (And on that note, I'm bummed that the conclusion in the article is to do that, especially because everytime this comes up, there's an uproar.) But, jeez. Just tuck it away so futzing with it is an opt-in decision for the 5% of the time that you need to make sure you aren't committing all of your changes. (And on note #2, if a person is doing partially staged changes more often than that, my question is why? What kind of chaotic, stream-of-consciousness style of development leads to that, and is it even producing good results? It doesn't take especially careful planning to not end up in the scenarios where partially committed changes is the answer.)

Often I'll work on a large change and make sure that it is working before I start crafting my commits. By the time I get to that point, I realize that I've actually made three separate subchanges so I do partial stages to create each commit.

I use git status -s and git diff quite a bit as a sanity check (for things like whitespace) and to do first party code review before I send anything out.

The staging area is a core part of my personal git workflow pre-commit. It seems to be producing good results so far.

> I realize that I've actually made three separate subchanges so I do partial stages to create each commit.

You can trivially replicate that without staging by amending the HEAD commit, or building a bunch of partial commits then folding them with rebase -i. You can even do that automatically by committing with --fixup or --squash

That assumes that I'm making multiple smaller commits along the way. I'm not. Without staging, I'm stuck making one big commit. Splitting a single big commit into multiple smaller commits with an interactive rebase is dependent upon the staging area too.

> That assumes that I'm making multiple smaller commits along the way. I'm not. Without staging, I'm stuck making one big commit.

Errr… no you're not. `commit -p` exists.

I have ADHD, so often as I am working on one feature, I will begin accidentally working on another unrelated feature along side it. I rely on staging a lot to ensure that each commit has only the parts that it needs.

Same here, I actually find `git add -p` to be very useful.

commit also has a -p flag.

Oh wow. No need for me to use git add ever again!

EDIT: I suppose I have to use it to add new files :)

Just use `git add -i` to mix and match :)

For my first couple _years_ with Git, I just passed the -a flag in upon every commit. This is a pretty easy, low effort habit to form, so this reduces to a question of which default to set. Git's approach seems to be that the default should be to nudge users toward power usage, which I don't think is necessarily a bad thing. (Note that git's approach to defaults in other areas, like potentially destructive actions, is actually a problem).

If you consider the use case "linux kernel development", you realize that you really don't want to automatically commit all your changes.

...and why is kernel development any different to any other large scale project?

I do consider the LKML-centric use case. (Often—probably more often than most.) No such realization is setting in. How about you elaborate?

Git doesn't actually make people deal with staging for every commit, though.

It's quite common to tell newcomers to always `git commit -a`, and `git add` for adding new files. That's pretty much exactly where SVN is/was, and nobody complained about that being complicated or onerous either.

You probably want "git add -N"; otherwise "git diff" won't work as expected.

As the author points out, it is an unnecessary primitive, once you learn about things like commit —amend, which you will inevitably eventually learn about anyway. Adding redundant ways to do the same thing is not the way to make a tool approachable.

The basic problem is that git was designed to solve Linus’s problems, and Linus’s problems are not your problems. However, because of network effects, most of us end up using the same tool.

How does commit --amend in any way solve the same problem as the staging area?

If I’ve got a big change which I want to split into three small internally consistent changes, with each change overlapping in many files, how in the world would --amend help?

It solves the problem I was directly replying to:

> I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go.

However, it does not replace all use cases of the staging area, which is why I gave it only as an example.

Of course, `commit --amend` with `-p` could solve your problem as well.

Alternatively, “create a new, 'pending’ commit, without a commit message, don’t point HEAD to it yet, and change most of the commit-related commands to modify this commit until it is finalized” also solves all the use cases of the staging area, because that is what the staging area is, but it is presented in a much more confusing way and ends up being yet another new concept for git beginners to grasp.

Fair points.

After thinking about this more, I find myself agreeing that in terms of beginner friendliness, the combination of incredible name confusion and the relative paucity of use cases where it’s necessary make the staging area an interesting area for significant change in the git defaults.

90% of VCS commits are simple enough to not need staging in my experience. That you can stage your changes does not mean that you need to be forced to do that. This is the point the article tries to make: streamline the workflow, but do not remove the feature for power users (people like you).

I believe there's a flag to `commit` that effectively does `add .` first.

I disagree with your statistic though - I can't tell you what the flag is precisely because it's almost never what I want; so I never use it and haven't learnt it.

I think these things just vary with workflow.

Just for completeness sake, the command to do that would be

  git commit -a

It does an implicit git add -u (which does not add new files not yet part of the repo)

I record my uses of each command and the current counts are the following (g is my shell alias for git):

    161 g cap      # commit --patch --amend
    170 g adu      # add -u
    205 g add -p   # add --patch
    277 g ci       # commit -a
    484 g cip      # commit --patch

At least, I use it a lot. ;)

So you disagree based on your personal experience? That is fine. I base my observation on what the people around me were using in various environments, so I am actually fairly confident that this can be generalized. This is the best I can do unless someone makes some representative statistics over a broad user base.

But why not use a mechanism that already exists - local commits. That way you also get a complete history of changes (including rollbacks), can write incremental commit messages, and can squash everything partially or completely at the end.

I made myself a few alias to use this approach. After a few months of use I can say staging is practically unnecessary for me. There were a few edge cases, but maybe I was just falling back to known solutions. I'm in favor of dropping staging.

How do you test the thing you're actually committing without everything else in your working tree contaminating your test?

There are ways to do this using stash but if you stash before you commit, you get merge conflicts when you pop the stash. The workaround I've seen is to commit before you stash, but that means you're also committing before you've actually tested that change, which seems pretty broken, IMHO.

I've created a script for this, it applies the staged changes to a fresh clone and executes the command you specify. To quote from --help:

If you have lots of unrelated uncommitted changes in the current repository and want to split up the commit, how can you easily check if the changes passes the test suite? With all the other unrelated changes it can be hard to make sure that only relevant changes becomes part of the commit, and that they don't result in regressions. This script clones the repository to the directory ".testadd.tmp" in the current directory and applies the staged changes there (unless -u/--unmodified or -p/--pristine is specified), chdirs to the same relative directory in the clone and executes the command specified on the command line there.

It's available from

https://github.com/sunny256/utils/blob/master/git-testadd

and the test suite (place it in a subdirectory below the script) is at

https://github.com/sunny256/utils/blob/master/tests/git-test...

It's stable, and I've been using it almost every day for 1.5 years. It also works with binary files.

Commits are just a bit of local data. Until you push it out somewhere public, it's all just a big mushy pallette to do with as you will.

Create a new branch for each issue where you create broken untested garbage commits with meaningless messages like "Fix".

When you're done:

git checkout master

git merge --squash <branch_name>

git commit -m "<Real commit message here>"

My problem with the staging area is it produces commits which never "exist" (that is, that code was probably never compiled/tested in isolation).

I'd be happier if the staging area was handled at the filesystem level, give me a directory which at all times contains the staging area, so I can test it.

Your CI system can test those commits in isolation. I frequently push supposed-to-be-stable commits like that alone to my working branch on Github, so Travis CI can tell me if I have a problem. Though I'm quite picky about commits, that each merge point into mainline (master) is tested is what is most important to me. Github PRs with Travis CI for instance enforce that pretty OK. If I don't bother to do a PR, and the changes as a linear set upon master, I like to use git merge --no-ff master to force a merge commit.

To me staging is the best part of git. I don't want to commit all the time so I slowly stage changes that I think are OK. Once the feature is done I can do a full commit. Perfect!

The author purports that this can be achieved without staging. For example, you could slowly commit small changes that you think are ok on a work-in-progress feature branch with `git commit -p --allow-empty-message`. When you are done you could squash rebase + message rewrite.

While currently this workflow is clunky, it could be made to work with the same nice semantics of your workflow, and not have a staging area at all.

Sure. I can get the same result I can get with simple staging with a complicated squash workflow. But why would I do that?

I have seen people get in trouble with rebasing and generally while manipulating history but never with the staging area.

> I have seen people get in trouble with rebasing and generally while manipulating history but never with the staging area.

I think that's what mercurial tries to solve, it makes manipulating history safe (by tracking the state of the commits, whether they were published or not for example, and always keeping all the history but hiding it after it was rewritten).

I should add. I always use a GUI like SourceTree for staging. With the command line it's much less fun.

The thing is that you don't need a staging area for that. The staging area is an unnecessarily complicated way to address this particular problem.

More importantly, the article is about the staging area being there by default.

This, exactly. What's so hard about one more command? If you really want a "save all" , just `git commit -a`.