New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rethink variables and arguments #2993
Comments
While I appreciate the difficulty in satisfying all users' wishes with regards to this functionality, I will mention that I personally make some of these variables buffer-local and set them with directory-local variable files in git-repos. Starting with Emacs 26, a second |
Just leaving this here for now: "Add configuration options for some commonly used command-line options" @ https://public-inbox.org/git/vpqa88hlghm.fsf@anie.imag.fr/T/. |
Thanks for magit, I use it daily! Is there still no way to enable |
@dhess This is probably a bit hacky and not the more elegant approach proposed by this issue (and it's technically per-directory not per-repo), but FWIW having this in (
(magit-status-mode . ((transient-values . ((magit-commit "--signoff")))))
) (Note this clobbers any other customisations of |
Both Git as well as Emacs come with powerful and flexible configuration methods. Magit embraces both Git and Emacs and that leads to conflicts with regards as to which setting wins in case of a conflict between Git and Emacs.
This has lead to surprisingly few complains in the past. Probably because it's usually "Emacs" that wins, and that's what Emacs users expect. However I intend to make Magit more useful for people who do not otherwise use Emacs. One group of such potential users are die hard command line users, who will be lured by the promise that Magit is "just like Git, but the output is actionable". Those users will be put off if their Git configuration is being ignored. And it only makes it worse that this isn't always the case.
I intend for Magit to move closer to Git with regards to configuration.
One prominent place where breaking changes are required are the popups used to invoke
git
. These have multiple issues and the ones relevant here are:The offered arguments are curated. It is possible for a user to add additional arguments, but that is somewhat cumbersome. For details see Allow users to select arguments to be shown in a popup #2941.
The popups show whether a given argument is active or not (i.e. whether it will be passed to
git
). It does not show whether the corresponding optional behavior is enabled or not; the argument might not be used, but the corresponding Git variable might be set to the equivalent value. This isn't really different fromgit
on the command line, there you also have to remember what variables you have set. But I still think Magit could/should present this information in a way that allows users to be certain whether the optional feature is enabled or not.One difficulty is that a "feature switch" now has more than two states, so we can no longer represent the current state simply by making the argument gray or colorful.
It is possible to permanently set the default arguments for a given popup and therefor the corresponding
git
subcommand (when invoked from that popup). This is done by storing the currenly active arguments in an global elisp variable. Beside the "set" variant there is also a "save" variant, which saves the variable for future Emacs sessions.The values saved like this affect all repositories (there are some complications, but lets assume that is always the case). But when using
git
itself, it is possible to use different default values in different repositories, by setting Git variables.Magit should do the same. I.e. arguments should be saved by setting Git variables. It should be possible to save them either globally or only for the current repository, and it should also be possible to reset an active popup to the the saved global or local state.
This has come up before in Set initial values of popup arguments based on Git variables #2610.
If an argument is saved by setting the corresponding variable to the appropriate value, what should then be shown in the popup? The argument or the variable?
A user might want to use a certain feature by default in Magit, but not on the command line. If the same mechanism is used to configure both, then how to allow this? Should we maybe (optionally) prefix the Git variables with "magit"?
Other issues touching on this, include Planned spin-offs and new packages #2956 and Finally replace magit-popup with a more capable implementation #2957.
{TODO extend this}
The text was updated successfully, but these errors were encountered: