4 ms·

Magit is great, I’ve used it every day for 10 years or something. There’s just one thing I haven’t got used to: 1. Stage some stuff 2. Start writing the commi

Magit is great, I’ve used it every day for 10 years or something. There’s just one thing I haven’t got used to: 1. Stage some stuff 2. Start writing the commit message 3. Stage something else 4. Commit The content staged at (3) doesn’t make it into the commit. This doesn’t fit my mental model from the command line: I think of “commit” as transfer all the staged content into a commit. Initially magit didn’t do this, but I know it is intentional, and in fact the magit author has explained to me that it accurately reflects the command line. But I just seem totally unable to get used to it! I might even change it locally.

iLemming 7y ago
Seems you need to get comfortable with rebasing. Don't think about your commits (especially if you haven't pushed them out) like something carved in stone. When I work, depending on what I'm doing I either commit often and don't think much about it and then later rebase and group things into meaningful chunks of work, or I just keep committing into a single commit and then at some point break it apart into smaller commits. Most often though I do try to keep commits nice and clean from the get-go, and very often I want to add something into a commit that's a few hashes away from the HEAD. In that case I would just rebase/modify with autostash option. It will stash everything and get into rebase mode, I'll go into the stash, select things I want to be included in the commit and press `a`, then I continue rebasing, it will modify the commit, un-stash and get me to the point where I was before.
- Myrmornis 7y ago
  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.
deleted 7y ago
[deleted]

iLemming 7y ago

Seems you need to get comfortable with rebasing. Don't think about your commits (especially if you haven't pushed them out) like something carved in stone. When I work, depending on what I'm doing I either commit often and don't think much about it and then later rebase and group things into meaningful chunks of work, or I just keep committing into a single commit and then at some point break it apart into smaller commits. Most often though I do try to keep commits nice and clean from the get-go, and very often I want to add something into a commit that's a few hashes away from the HEAD. In that case I would just rebase/modify with autostash option. It will stash everything and get into rebase mode, I'll go into the stash, select things I want to be included in the commit and press `a`, then I continue rebasing, it will modify the commit, un-stash and get me to the point where I was before.

Myrmornis 7y ago
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.

deleted 7y ago

[deleted]