5 ms·

Thanks but sorry, you've missed the point of my post. If you have time, please read it again. I'm pointing out that, if you think of C-c C-c in the commit buffe

Thanks but sorry, you've missed the point of my post. If you have time, please read it again. I'm pointing out that, if you think of C-c C-c in the commit buffer as being "commit", then there's an uncomfortable conclusion: magit doesn't put everything that is currently staged into the commit. Instead what magit does is freeze the contents of the commit when you open the commit message composition buffer, so anything staged subsequently doesn't make it into the commit. (In my original message I do say i've been using magit daily for 10 years; i'm extremely familiar with all the rebasing operations you mention. i agree they're very useful and i use them multiple times a day.)

iLemming 7y ago
No, I think I get what you want the first time I read it. So I did a little experiment (just to make sure I'm not wrong about it). I did everything in the command line. I staged a file, then run git commit, when it opened the editor, I switched to another terminal window and staged another file. Then I switched back and finished committing. And surely enough, just as I expected - git did not commit two files, but only one and the other stayed staged. So the feature you're asking is not even supported by Git. And the reason you want that feature, because Magit has spoiled you - when almost everything is nonlinear (unlike with git cmd), you want to extend it even further. Let's be pragmatic, don't complain that it is great that Tesla has autopilot option but you actually wanted it to be an amphibious vehicle, because you live next to a lake.
- Myrmornis 7y ago
  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?
  - iLemming 7y ago
    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.
    - Myrmornis 7y ago
      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. (defun myrmornis--magit-commit-staged () (interactive) (let ((commit-message (buffer-string))) (let ((with-editor-cancel-message "")) (with-editor-cancel nil)) (with-temp-buffer (insert commit-message) (goto-char (point-min)) (delete-matching-lines "^[ \t]*#") ;; hack (magit-run-git-with-input "commit" "-F" "-"))) (magit-refresh-all)) (use-package magit :bind (:map with-editor-mode-map ("C-c C-c" . myrmornis--magit-commit-staged))
      - iLemming 7y ago
        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. As I said, maybe there are people who'd find it extremely useful. Would you mind sharing your "hack" in https://github.com/magit/magit https://github.com/magit/magit or https://gitter.im/magit/magit https://gitter.im/magit/magit ?

iLemming 7y ago

No, I think I get what you want the first time I read it. So I did a little experiment (just to make sure I'm not wrong about it). I did everything in the command line. I staged a file, then run git commit, when it opened the editor, I switched to another terminal window and staged another file. Then I switched back and finished committing. And surely enough, just as I expected - git did not commit two files, but only one and the other stayed staged. So the feature you're asking is not even supported by Git. And the reason you want that feature, because Magit has spoiled you - when almost everything is nonlinear (unlike with git cmd), you want to extend it even further. Let's be pragmatic, don't complain that it is great that Tesla has autopilot option but you actually wanted it to be an amphibious vehicle, because you live next to a lake.

Myrmornis 7y ago
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?
- iLemming 7y ago
  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.
  - Myrmornis 7y ago
    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. (defun myrmornis--magit-commit-staged () (interactive) (let ((commit-message (buffer-string))) (let ((with-editor-cancel-message "")) (with-editor-cancel nil)) (with-temp-buffer (insert commit-message) (goto-char (point-min)) (delete-matching-lines "^[ \t]*#") ;; hack (magit-run-git-with-input "commit" "-F" "-"))) (magit-refresh-all)) (use-package magit :bind (:map with-editor-mode-map ("C-c C-c" . myrmornis--magit-commit-staged))
    - iLemming 7y ago
      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. As I said, maybe there are people who'd find it extremely useful. Would you mind sharing your "hack" in https://github.com/magit/magit https://github.com/magit/magit or https://gitter.im/magit/magit https://gitter.im/magit/magit ?