Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Dieter Komendera
    @kommen
    can this be a naming collision issue with the defcustom and the defun both named magit-save-repository-buffers?
    Dieter Komendera
    @kommen
    my elisp foo is not strong enough to figure out what is going on here
    Noam Postavsky
    @npostavs
    @kommen can't be a naming collision, variables and functions have separate namespaces. Have you tried recompiling magit (and perhaps related packages)? There are sometimes incompatibilities across Emacs versions that can get baked into the .elc files and cause strange behaviour.
    Dieter Komendera
    @kommen
    @npostavs yes, I tried recompling and re-installing as well
    my last findings where, that using (debug) before the linked eq above, evaluating (type-of magit-save-repository-buffers) says it is a cons, where as doing the same in ielm results in symbol
    Noam Postavsky
    @npostavs
    @kommen What does evaluating magit-save-repository-buffers from the debugger give you?
    Dieter Komendera
    @kommen
    @npostavs 'dontask
    but (eq magit-save-repository-buffers 'dontask) is nil
    Noam Postavsky
    @npostavs
    @kommen the ' is included in the evaluation result?
    Dieter Komendera
    @kommen
    yes
    (car magit-save-repository-buffers) returns quote
    Noam Postavsky
    @npostavs
    Is that the case at the top-level in ielm as well, or just in the debugger frame?
    Dieter Komendera
    @kommen
    just in the debugger frame
    Noam Postavsky
    @npostavs
    Sounds like something is modifying the value in a strange way. I suggest doing M-x debug-on-variable-change magit-save-repository-buffers RET to catch where that happens.
    Dieter Komendera
    @kommen
    Debugger entered--killing local value of magit-save-repository-buffers in buffer magit: ars: debug--implement-debug-watch(magit-save-repository-buffers nil makunbound #<buffer magit: ars>) kill-all-local-variables() special-mode() magit-section-mode() magit-mode() magit-status-mode()
    Dieter Komendera
    @kommen
    @npostavs thanks for your help. I don't think it is worth for me right now to continue down that rabbit hole
    Noam Postavsky
    @npostavs
    @kommen that change is probably okay (although I'm not sure why it's local in the first place), so type c to continue from there.
    Dieter Komendera
    @kommen
    but this is the last change to that variable:
    Debugger entered--setting magit-save-repository-buffers in buffer magit: ars to 'dontask: debug--implement-debug-watch(magit-save-repository-buffers 'dontask set #<buffer magit: ars>) hack-one-local-variable(magit-save-repository-buffers 'dontask) hack-local-variables-apply() hack-dir-local-variables-non-file-buffer() magit-status-mode() magit-setup-buffer-internal(magit-status-mode nil ((magit-buffer-diff-args ("--no-ext-diff")) (magit-buffer-diff-files nil) (magit-buffer-log-args ("-n256" "--decorate")) (magit-buffer-log-files nil)))
    Noam Postavsky
    @npostavs
    @kommen ah, looks like you have a wrong setting in a .dir-locals.el file
    Dieter Komendera
    @kommen
    @npostavs damn
    so there is (magit-save-repository-buffers . 'dontask) in there, and I guess the quote is wrong
    Noam Postavsky
    @npostavs
    yep
    Dieter Komendera
    @kommen
    thanks! interesting that this now only pops up with emacs 27, it is in there since a couple of months that way...
    asymmetric
    @asymmetric
    can i merge a PR using forge by merging the branch into its upstream and pushing? Will that mark the PR as merged?
    found magit/forge#96, answers my question
    asymmetric
    @asymmetric
    is it possible to customize which suffixes are shown?
    e.g. by specifying a threshold
    asymmetric
    @asymmetric
    found out how to do it: activating the option then asks for a level
    beautiful implementation! :heart:
    Rudi Grinberg
    @rgrinberg
    Is there a way to create a forge PR and immediately set the reviewers?
    s/forge PR/PR created with forge/
    Magnus Therning
    @magthe
    @rgrinberg the only way I know is to use .github/CODEOWNERS
    donahchoo
    @donahchoo
    The org that my GHE repo is in has changed. Is there a way to get magit/forge to use the updated org name without having to reclone the repo?
    donahchoo
    @donahchoo
    I think I did this by renaming origin and then using b u to unset the remote and then set it.
    Rudi Grinberg
    @rgrinberg
    I see. Thanks anyway.
    Is there a way to change log settings for the current log buffer?
    For example, I'd like to add the diff stat to the current log with -s
    Kévin Le Gouguec
    @peniblec

    Hi! Sorry for the repost, but I still haven't figured this out:

    Quick question (hopefully): when global-magit-file-mode is t (the default), does one still need to (require 'magit) in their init file in order to enable magit-file-mode bindings?
    My .emacs does not (require 'magit) ATM and C-x g and other shortcuts do not seem to work until I manually call M-x magit-status once. Adding (require 'magit) in the init file fixes this. Is this expected?
    The installation node in the manual explicitly says to (require 'magit) when installing from the Git repository, but no such step is mentioned in "Installing from Melpa" nor in "Post-Installation Tasks".
    (Tested with Emacs 28)

    (My curiosity was renewed by Stefan's recent message on emacs-devel explaining why one shouldn't, in principle, (require 'foo) in their init file)

    @rgrinberg

    For example, I'd like to add the diff stat to the current log with -s

    Butting in without having read the rest; does L -s g in a log buffer do what you want?

    Kévin Le Gouguec
    @peniblec

    @rgrinberg

    Is there a way to change log settings for the current log buffer?

    L (uppercase) allows you to change the current log buffer's settings; once you've (un)set the parameters, hit g to refresh.

    Rudi Grinberg
    @rgrinberg
    Thanks peniblec
    Kévin Le Gouguec
    @peniblec

    @tarsius I'd appreciate it if you could weigh in on my question above; tl;dr must a user add (require 'magit) to their init file to make C-x g work without first running magit-status, even though global-magit-file-mode is t?

    It's not terribly important so no rush though. I don't know if Gitter is the best place to ask; my impression is that this is too trivial to warrant a Github issue or a post on StackExchange…

    Oliver
    @or
    Howdy, folks. I'm trying to add an extra switch to magit-rebase, finally found transient-append-suffix and it does what I want. But I can't figure out how to set the default value of a switch (also of existing switches). The docs I found only talk about magit-popup. I did see there's :value in define-transient-command, but can I set that for an existing transient command?
    Jonas Bernoulli
    @tarsius
    @peniblec That should not be necessary but Magit's autoloads file has to be loaded.
    Oliver
    @or
    @tarsius: Marvellous, thank you!
    Kévin Le Gouguec
    @peniblec

    @tarsius Mmm; is that something that package.el is supposed to handle automatically? I can see magit-autoloads.el under ~/.emacs.d/elpa/magit-2020..., and I guess something is autoloaded, because magit-status shows up right from the start when I M-x magit- TAB, but magit-file-mode-map bindings are not loaded until I run magit-status or (require 'magit) :/

    If that helps, I'm running Emacs 28 (but I've observed this behaviour with previous Emacs versions too), I don't have any customization on package.el-related variables (that I know of), and I installed magit from MELPA using package.el...

    Let me know if you want me to make a proper issue out of this.

    Jonas Bernoulli
    @tarsius
    Once in a blue moon I have to explicitly invoke magit-status before I can use magit-file-dispatch too. I have tried investigating it before and eventually I will give it another try. For now you might occasionally (or in your case always?) invoke magit-status first. Sorry.