What is git staging and why does Hg *ostensibly* not support it?

Question

The Hg docs state that hg doesn't support an equivalent to git's index out of the box and suggests using extensions (record or mq) for similar behaviour.

First, I have very little field experience with git, so let me state my understanding of the concept of staging in git:

• There's the working copy, containing a number of changed files, each having a number of changed chunks.
• The user then (maybe repeatedly) uses git add to select which files will be committed.
• Alternatively, use git add -p to select only some of the chunks in a file to later be committed.
• Do a git commit to add the previously selected changes to the repository.

So the whole staging area, to me, is a pompous name for a selection of which of the changes in the working copy will make it in the next commit.

If I'm not completely off on that, then, why does everyone, including the official documentation, state that Mercurial does not support this?

I'm asking, because the exact workflow above is trivial in TortoiseHg:

• in the left pane - select whole files to include in the commit
• in the right bottom pane - select single chunks to include
• hit 'Commit'.

I don't know what hg commands TortoiseHg uses, but then again, I never needed to care. (It doesn't make use of any extension for this AFAICT)

Is there more to the git concept of staging that I'm missing?

Answer 1

The staging area (index) records change snapshots, not just a selection of files. For instance, you can modify file A to add foo, stage file A, then modify file A again to add bar. If you don't re-stage file A, then when you commit, only foo will be committed, because the index has the snapshot of A when it was staged.

You can also revert a file back to the state of the last index snapshot (via git checkout). Essentially, the index acts like a "temporary commit" that is easy to modify before actually being promoted to a full commit.

Since the index is persistent, if you get halfway through staging things, then decide you need to make another change, no problem - just go make the change, then stage the new version. No need to re-stage all of the other things you've already staged.

Accidentally delete a file before committing? If you already staged it, no worries - just check out the staged version.

Answer 2

Git was designed to support certain kind of workflow during Linux kernel development. By certain kind of people for certain kind of people.

It is not designed to be easy to use by ordinary developer (compare with hg!) but gain large popularity and cultural status due to its cost, performance, large company support and advertising campaign (GitHub here).

Today ordinary developer interact with Git via IDE GUI and don't need to know about Index/Stage area. It just uses checkboxes like in asker screen-shot (so there are no difference between Git/Mercurial usage for ordinary developer).

For people working with command line irregular CLI syntax of Git and exposing unnecessary storage format details make learning line longer in compare to time to become Mercurial wizard.

Here is nice images that describe Index usage:

• https://marklodato.github.io/visual-git-guide/index-en.html
• http://git-scm.com/blog/2011/07/11/reset.html

You alway may emulate Index by (but why?):

hg qinit
hg qadd
hg qrefesh
hg qfinish

except MQ allow you to have an ordered set of Indexes, not just one! And allow you give name to each "Index".

With record extension you have option to select patch chunks in CLI like you check checkboxes in GUI. That extension is direct answer to Git -p option.

So topic starter is actually right in its filling that Index is unnecessary feature of DVCS architecture, and built into Git to support willing of some Git core developers.

Good luck and happy hacking!

UPDATE Quotation from http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/

Most of the power of Git is aimed squarely at maintainers of codebases: people who have to merge contributions from a wide number of different sources, or who have to ensure a number of parallel development efforts result in a single, coherent, stable release. This is good. But the majority of Git users are not in this situation: they simply write code, often on a single branch for months at a time. Git is a 4 handle, dual boiler espresso machine – when all they need is instant.