5 ms·

"I find [the index] a critical part of git's culture of making small commits with one logical change each." I've never understood why the index has to be force

by krupan 11y ago

"I find [the index] a critical part of git's culture of making small commits with one logical change each." I've never understood why the index has to be forced on everyone for every commit. Apparently it's due to a belief that everyone always just munges a bunch of changes together in their working copy in a mad coding frenzy and then later realize they need to filter and separate those changes into separate commits? That happens to me from time to time, but it's not the common case. When it does happen (since I use mercurial) I can use use tools such as commit --amend, or commit <list of filenames>, or record or crecord to filter and separate the changes in my working copy into separate commits. I believe even git has some of those same options.

ngoldbaum 11y ago
In recent versions the "record" extension has been replaced by "hg commit -i". Many other commands support interactive hunk selection as well.
JoshTriplett 11y ago
> "I find [the index] a critical part of git's culture of making small commits with one logical change each." > I've never understood why the index has to be forced on everyone for every commit. You can generally bypass it if making a simple commit; I use "git commit -a" all the time. But every time you use tools like "git add" on individual files, or "git add -p" on parts of files, you rely on the index. Understanding the index also helps greatly when you need to do a merge, cherry-pick, or other similar operation; you need a staging area to work in, separate from the work tree.
- krupan 11y ago
  "Understanding the index also helps greatly when you need to do a merge, cherry-pick, or other similar operation; you need a staging area to work in, separate from the work tree." Actually, with mercurial I don't need a staging area to work in separate from the working copy to perform merge, cherry-pick, or other similar operations. The index appears to be needless complication.
  - scrollaway 11y ago
    Having used both git and mercurial extensively I can guarantee you the index is not a needless complication, it is a feature sorely missed in hg.
    - jordigh 11y ago
      With `hg commit --interactive` and `hg amend --interactive`, I really don't see what's the difference between a temporary commit that you keep adding stuff to and a staging area. It's all just diffs and hunks. Whether it's finalised or not is just a matter of perspective. Mercurial encodes this perspective by distinguishing draft from published commits.

by krupan 11y ago

ngoldbaum 11y ago

In recent versions the "record" extension has been replaced by "hg commit -i". Many other commands support interactive hunk selection as well.

JoshTriplett 11y ago

> "I find [the index] a critical part of git's culture of making small commits with one logical change each." > I've never understood why the index has to be forced on everyone for every commit. You can generally bypass it if making a simple commit; I use "git commit -a" all the time. But every time you use tools like "git add" on individual files, or "git add -p" on parts of files, you rely on the index. Understanding the index also helps greatly when you need to do a merge, cherry-pick, or other similar operation; you need a staging area to work in, separate from the work tree.

krupan 11y ago
"Understanding the index also helps greatly when you need to do a merge, cherry-pick, or other similar operation; you need a staging area to work in, separate from the work tree." Actually, with mercurial I don't need a staging area to work in separate from the working copy to perform merge, cherry-pick, or other similar operations. The index appears to be needless complication.
- scrollaway 11y ago
  Having used both git and mercurial extensively I can guarantee you the index is not a needless complication, it is a feature sorely missed in hg.
  - jordigh 11y ago
    With `hg commit --interactive` and `hg amend --interactive`, I really don't see what's the difference between a temporary commit that you keep adding stuff to and a staging area. It's all just diffs and hunks. Whether it's finalised or not is just a matter of perspective. Mercurial encodes this perspective by distinguishing draft from published commits.