3 ms·

> I originally saw the index as an obstacle to the commit model I'd gotten used to from subversion. Today, I find it a critical part of git's culture of making

> I originally saw the index as an obstacle to the commit model I'd gotten used to from subversion. Today, I find it a critical part of git's culture of making small commits with one logical change each. How is this different from mercurial ? I know that the latter doesn't have the index, but is there any practical difference from the point of view of the user ? In Mercurial you can easily commit a subset of the files, or even a part of a file if you use the record extension.

jordigh 11y ago
> if you use the record extension. It's now part of core with `hg commit -i`, although it's still experimental.
pekk 11y ago
Have you used both? You can commit a subset of changed files in most version control systems, but it isn't smart because you didn't test that state and it's relatively easy to garble files. Not having the index is a very practical difference for users, because it means that you do not get any editable "staging" commits, only commits that will be on the permanent record.
- mrighele 11y ago
  Thanks for clarifying, my experience with Git is much more limited than with Mercurial, so it wasn't clear to me that the index is a sort of editable (or partial?) commit (of course now it looks quite obvious). I understand the appeal of that, in fact Mercurial acquired similar capabilities during it's evolution, thanks to a number of extensions (for example histedit [1]) [1] https://www.mercurial-scm.org/wiki/HisteditExtension https://www.mercurial-scm.org/wiki/HisteditExtension
- krupan 11y ago
  But nothing in git (or any dvcs, really) is "permanent record" until you share it with others. git users are very proud of git's history editing capabilities, in fact. So no need for an index, just commit, and edit that commit if needed.
- rbehrends 11y ago
  > You can commit a subset of changed files in most version control systems, but it isn't smart because you didn't test that state and it's relatively easy to garble files. The clean solution here is to stash/shelve the changes you don't want, then commit the ones you wanted. This works pretty much the same way in either VCS. > Not having the index is a very practical difference for users, because it means that you do not get any editable "staging" commits, only commits that will be on the permanent record. Use hg commit [-i], hg commit --amend [-i], and hg uncommit (with evolve) to modify the most recent commit as needed. Or, frankly, just use hg shelve [-i] to do the reverse as described above. The Git index doesn't improve upon the situation, since you still can't test the partial commit without stashing the remaining changes first. At which point you could have just done that first. In any event, the closest equivalent of Git's index in Mercurial is MQ, not hg commit -i and friends. The difference is that in Mercurial it's opt-in rather than opt-out.

jordigh 11y ago

> if you use the record extension. It's now part of core with `hg commit -i`, although it's still experimental.

pekk 11y ago

Have you used both? You can commit a subset of changed files in most version control systems, but it isn't smart because you didn't test that state and it's relatively easy to garble files. Not having the index is a very practical difference for users, because it means that you do not get any editable "staging" commits, only commits that will be on the permanent record.

mrighele 11y ago
Thanks for clarifying, my experience with Git is much more limited than with Mercurial, so it wasn't clear to me that the index is a sort of editable (or partial?) commit (of course now it looks quite obvious). I understand the appeal of that, in fact Mercurial acquired similar capabilities during it's evolution, thanks to a number of extensions (for example histedit [1]) [1] https://www.mercurial-scm.org/wiki/HisteditExtension https://www.mercurial-scm.org/wiki/HisteditExtension
krupan 11y ago
But nothing in git (or any dvcs, really) is "permanent record" until you share it with others. git users are very proud of git's history editing capabilities, in fact. So no need for an index, just commit, and edit that commit if needed.
rbehrends 11y ago
> You can commit a subset of changed files in most version control systems, but it isn't smart because you didn't test that state and it's relatively easy to garble files. The clean solution here is to stash/shelve the changes you don't want, then commit the ones you wanted. This works pretty much the same way in either VCS. > Not having the index is a very practical difference for users, because it means that you do not get any editable "staging" commits, only commits that will be on the permanent record. Use hg commit [-i], hg commit --amend [-i], and hg uncommit (with evolve) to modify the most recent commit as needed. Or, frankly, just use hg shelve [-i] to do the reverse as described above. The Git index doesn't improve upon the situation, since you still can't test the partial commit without stashing the remaining changes first. At which point you could have just done that first. In any event, the closest equivalent of Git's index in Mercurial is MQ, not hg commit -i and friends. The difference is that in Mercurial it's opt-in rather than opt-out.