Committing always pops the `options` buffer #766

Closed
bradwright opened this Issue Aug 17, 2013 · 8 comments

Projects

None yet

3 participants

@bradwright
Contributor

I used to be able to just hit c and type. Now I have to type c...c. Is this change intentional?

@tarsius
Member
tarsius commented Aug 18, 2013

Yes, this is intentional. You can however use magit-commit directly without using the popup:

(define-key magit-mode-map "c" 'magit-commit)

Then use a prefix argument to amend but other options offered by the popup are lost.

@bradwright bradwright added a commit to bradwright/emacs-d that referenced this issue Aug 18, 2013
@bradwright bradwright Don't show commit options unless forced
Passing a prefix command to "c" in the Magit buffer will cause the
options to be shown. I don't miss the 'amend' functionality for two
reasons:

1) I can call it explicitly from the commit options; and
2) I can use `C-c C-a` from within the commit buffer to make that commit
an amend anyway.

Works around magit/magit#766
c0a452f
@bradwright
Contributor

Excellent, thanks. I've made a function that broadly does what I want (in the referenced commit above).

@bradwright bradwright closed this Aug 18, 2013
@tarsius
Member
tarsius commented Aug 18, 2013

Reopen so I don't forget to look at your workaround.

I actually considered doing something similar to what you are doing, but decided to delay think about it some more until I have made some changes to the key-mode.

Toggling --amend while editing the commit message does not work any more. This is one of the drawbacks of git-commit-mode compared to magit-log-edit-mode. I think it makes more sense to decide whether to amend or not before editing the commit message. (Among other things this makes it easier to edit the old message instead of rewriting it from scratch.)

Generally I think doing it the way it is done now makes more sense, and the only major drawback is that in the trivial case c has to be pressed twice and the popup flashes shortly.

@tarsius tarsius reopened this Aug 18, 2013
@bradwright
Contributor

Thanks for taking a look and taking the time to discuss.

I think it makes more sense to decide whether to amend or not before editing the commit message.

I agree with that. My existing C-c C-a workflow was predicated on the way it used to work, which is a bit broken, so I should unlearn that.

For me the trivial case is probably 90% of my usage, the other 10% being amending, so my workaround should be fine for my usage.

@tarsius
Member
tarsius commented Aug 23, 2013

For me the trivial case is probably 90% of my usage, the other 10% being amending, so my workaround should be fine for my usage.

Same here. I would recommend you try without your wrapper function first, and only start using it if you cannot get used to the default behaviour. Of course nobody knows better what you might or might not get used to than yourself, so by any means just do what ever you see fit :-)

I have however decided not to add something inspired by this to magit itself.

@tarsius tarsius closed this Aug 23, 2013
@jaseemabid

Using the snippet shared by @tarsius as a work around, but we should alert users about these kind of changes with a CHANGELOG.md file in the future.

@jaseemabid

Now I lost the C-a key binding to amend last commit. I read the other discussion threads but its not obvious on how to bring back the amend option once you are in a message buffer, be it with C-a, C-r or C-m.

Is it a good idea to stick to a specific git version till all these issues are fixed? Also, I'm against the idea of fixing things in 2 steps because users might upgrade anytime.

@tarsius
Member
tarsius commented Aug 31, 2013

We broke things badly and are working hard on fixing. But that will take some time.

@tarsius tarsius added 11 commit and removed 11 new commit labels May 7, 2014
@tarsius tarsius removed the 11 commit label May 29, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment