Skip to content
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

Open
tarsius opened this issue Feb 13, 2017 · 4 comments
Open

Rethink variables and arguments #2993

tarsius opened this issue Feb 13, 2017 · 4 comments

Comments

@tarsius
Copy link
Member

tarsius commented Feb 13, 2017

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 from git 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}

@tarsius tarsius added the enhancement New feature or request label Feb 13, 2017
@gdobbins
Copy link
Contributor

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.

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 .dir-locals-2.el file is capable of setting directory local variables which affords the possibility of setting Magit options on groups of repos provided they are all contained beneath some shared directory. This provides an opportunity for customizing git's behavior which is not possible with git itself as far as I know.

@tarsius
Copy link
Member Author

tarsius commented Mar 21, 2017

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/.

@dhess
Copy link

dhess commented May 16, 2023

Thanks for magit, I use it daily!

Is there still no way to enable --signoff on a per-repo basis?

@projectgus
Copy link

projectgus commented Nov 16, 2023

Is there still no way to enable --signoff on a per-repo basis?

@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 .dir-locals.el of selected project working directories works for me:

(
 (magit-status-mode . ((transient-values . ((magit-commit "--signoff")))))
 )

(Note this clobbers any other customisations of transient-values, If that's an issue then I assume eval can be used to modify it instead.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants