Right, exactly. What you describe makes sense and is the reason why magit does what it does.
Now, note that you ran `git commit`, with no arguments. Let's think about an alternative narrative on the command line, involving `git commit -m "$message"`
1. Stage a file.
2. Start drafting your commit message.
3. Stage another file.
4. Finish drafting your commit message.
5. Issue git commit -m "$message"
This time, both files make it into the commit.
So basically, we are now thinking of the Magit commit composition buffer as a place where you draft a work-in-progress commit message.
I think we can both agree that the idea of having a place where you can draft your commit message, and meanwhile alter the contents of the staging area, is not unreasonable. Perhaps as an alternative to the standard flow.
So my question to you (and those who might consider working on magit code) is: what advantages does the other model have? (other than it mirroring `git commit` with no arguments). Would one ever really want to mess about with the contents of the staging buffer while you have a pending commit message that you have not yet actually committed? Isn't it in fact more likely that what you want to do, while that commit message is pending, is alter the details of what will be committed?
Sorry, the "problem" you have is just too alien to me personally. I never had any issues with that feature of Magit, never thought about it until now. Maybe there are people just like you who'd say it's important to them - I can't relate, once again: my apologies.
I'm sure this can be "fixed" by writing some non-trivial Emacs lisp by tapping into `with-editor-finish` or `magit-commit` functions. But honestly, is that worth your time?
Emacs is weird, it makes you want weird things. So many times I would find myself irritated by "an issue" that I just stumbled on, I would write some emacs lips to fix the problem (just because I can), only later to realize there's no problem to begin with.
There's no need to apologize! It's just two different possibilities for the design of Magit. I already wrote the code this morning to do this as a quick hack. It's just a few lines and I've been writing lots of emacs lisp recently, so it didn't cost me much time. The question is whether it would be useful as a setting for other magit users. Like I say, I can see arguments for this (being able to update you commit in conjunction with working on the commit message) but neither of us have suggested an advantage of the other model yet.
I apologized so it is clear that I'm not rejecting your idea due to my shallow thinking. Maybe you are trying to convey a story that potentially opens wide-range of possibilities and I just don't see it.
(Replying to a child node because we've hit a HN depth limit I believe).
Yep sure, I can open an issue to add a setting for this. I suspect it will be rejected but that's OK; I think an issue is justified because I use git and magit very intensively and have been unable to escape the `git commit -m` mental model.
Most people don't care about this scenario because it's so easy to amend a commit. If you're doing a "git commit" with no -m, you can just leave the commit message in a draft state, finish the commit, stage more changes, do "git commit --amend", and then continue editing the commit message.
The commit itself holds the draft of the commit message.
It becomes permanent when you stop tweaking the commit and publish it.
This thread is the illustration of how cool Magit is. We're discussing some esoteric feature that could potentially be nice to have. Not some basic stuff like: "this and that doesn't work!" or "how do you even do X?"
Now, note that you ran `git commit`, with no arguments. Let's think about an alternative narrative on the command line, involving `git commit -m "$message"`
1. Stage a file.
2. Start drafting your commit message.
3. Stage another file.
4. Finish drafting your commit message.
5. Issue git commit -m "$message"
This time, both files make it into the commit.
So basically, we are now thinking of the Magit commit composition buffer as a place where you draft a work-in-progress commit message.
I think we can both agree that the idea of having a place where you can draft your commit message, and meanwhile alter the contents of the staging area, is not unreasonable. Perhaps as an alternative to the standard flow.
So my question to you (and those who might consider working on magit code) is: what advantages does the other model have? (other than it mirroring `git commit` with no arguments). Would one ever really want to mess about with the contents of the staging buffer while you have a pending commit message that you have not yet actually committed? Isn't it in fact more likely that what you want to do, while that commit message is pending, is alter the details of what will be committed?