Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Committing always pops the `options` buffer #766

Closed
bradleywright opened this Issue · 8 comments

3 participants

@bradleywright

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

@tarsius
Owner

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.

@bradleywright bradleywright referenced this issue from a commit in bradleywright/emacs-d
@bradleywright bradleywright 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
@bradleywright

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

@tarsius
Owner

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
@bradleywright

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
Owner

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
@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
Owner

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
@tarsius tarsius removed the 11 commit label
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.