Not really. I'm not sure I want it to behave the way GP suggests, but I definitely want to have staging, and `git commit -a` is basically an equivalent of having no staging.
The reasons for that are:
1. In the vast majority of cases there are multiple files I want to commit together. Usually I change them multiple times during the process.
2. It almost always starts with some debugging in a couple of other files, and I often want to keep that debugging for a couple of next commits, but `git checkout HEAD` these files in the end.
3. For me, the most popular way of using git rebase → edit (which I do reasonably often) is splitting a commit into 2 by separating files. This is easy enough by just changing a status of a file from "staged" to "modified" (I even have `git unstage` alias for that) and commiting.
So I kinda get why GP wants what he wants. This isn't crazy.
Now, that being said, I personally have absolutely no problems with how git does that now: I've figured out a workflow that solves these problems for me, and everything is ok now. This workflow is basically making many dozens of tiny commits to a branch without even bothering to name them properly, and then just doing `git rebase -i` many-many times while working on a single branch. So I just commit the code I don't intend to keep with a label "drop that", and drop these commits when I'm done. And other commits usually are heavily reordered and squashed into 3-5 larger commits that make some sense on a higher level (like 500 LOC of refactoring first, and then 1 LOC of an actual bug-fix, which usually makes much more sense than just 500 LOC of a bugfix, that solve the problem somehow, but it's absolutely not obvious how exactly). I rarely can figure out that separation before I'm done. In fact, I often fix the problem first, then refactor, then roll-back the fix just to add it again in a separate commit in the end (if the refactoring and the fix affect the same file, which also is often the case).
> Not really. I'm not sure I want it to behave the way GP suggests, but I definitely want to have staging
So I'm replying to OP's very specific usage pattern, and you object with a completely different usage pattern?
> `git commit -a` is basically an equivalent of having no staging.
GP doesn't use the staging as a staging, since they immediately stage all modified files. That means the staging is useless, they can just commit files straight from modified. Which is what `git commit -a` does.
> 1. In the vast majority of cases there are multiple files I want to commit together. Usually I change them multiple times during the process.
OK? `git commit -a` doesn't preclude that. You just use it instead of `git commit`.
> 2. It almost always starts with some debugging in a couple of other files, and I often want to keep that debugging for a couple of next commits, but `git checkout HEAD` these files in the end.
I'm really happy for you. It doesn't work when the files are already staged, which is the case of GP.
> 3. For me, the most popular way of using git rebase → edit (which I do reasonably often) is splitting a commit into 2 by separating files. This is easy enough by just changing a status of a file from "staged" to "modified" (I even have `git unstage` alias for that) and commiting.
You don't need a staging area to craft commits, you can manipulate the tip commit directly. With good enough support for that (which sapling seems to have inherited from mercurial), the staging is just an unnecessary pseudo-commit.
The reasons for that are:
1. In the vast majority of cases there are multiple files I want to commit together. Usually I change them multiple times during the process.
2. It almost always starts with some debugging in a couple of other files, and I often want to keep that debugging for a couple of next commits, but `git checkout HEAD` these files in the end.
3. For me, the most popular way of using git rebase → edit (which I do reasonably often) is splitting a commit into 2 by separating files. This is easy enough by just changing a status of a file from "staged" to "modified" (I even have `git unstage` alias for that) and commiting.
So I kinda get why GP wants what he wants. This isn't crazy.
Now, that being said, I personally have absolutely no problems with how git does that now: I've figured out a workflow that solves these problems for me, and everything is ok now. This workflow is basically making many dozens of tiny commits to a branch without even bothering to name them properly, and then just doing `git rebase -i` many-many times while working on a single branch. So I just commit the code I don't intend to keep with a label "drop that", and drop these commits when I'm done. And other commits usually are heavily reordered and squashed into 3-5 larger commits that make some sense on a higher level (like 500 LOC of refactoring first, and then 1 LOC of an actual bug-fix, which usually makes much more sense than just 500 LOC of a bugfix, that solve the problem somehow, but it's absolutely not obvious how exactly). I rarely can figure out that separation before I'm done. In fact, I often fix the problem first, then refactor, then roll-back the fix just to add it again in a separate commit in the end (if the refactoring and the fix affect the same file, which also is often the case).