1. 05 May, 2018 2 commits
  2. 04 May, 2018 1 commit
  3. 07 Mar, 2018 1 commit
  4. 03 Feb, 2018 1 commit
  5. 24 Jan, 2018 1 commit
    • Jonas Bernoulli's avatar
      magit-confirm: Fix regression · 42c22614
      Jonas Bernoulli authored
      Unfortunately doing so means changing the function signature in a way
      that is not backward compatible.
      This function relies on being able to tell whether ITEMS is nil
      because that argument was not provided or because an empty list was
      provided as its value.  In the former case the action still has to be
      confirmed in the latter case it does not because there is nothing to
      act on.
      So the `(items nil sitems)' argument has to be last but in d6420549
      I added a new argument NOCONFIRM after it.
      Fixes #3341.
  6. 18 Jan, 2018 1 commit
    • Jonas Bernoulli's avatar
      magit-confirm: Abort if user doesn't confirm · d6420549
      Jonas Bernoulli authored
      Previously we left that for the callers to do.  Or not do - in
      a few cases we should not abort when the user doesn't confirm
      to allow other things to happen.  Add a new argument NOABORT
      to be used in those cases.
  7. 07 Jan, 2018 1 commit
  8. 02 Oct, 2017 1 commit
    • Jonas Bernoulli's avatar
      Don't enable with-editor-mode twice · 9be36868
      Jonas Bernoulli authored
      In `git-commit-setup' and `git-rebase-mode' do not enable
      `with-editor-mode' again if it is already enabled.  That mode may
      already enabled if the user commits or rebases using `*-shell-command'
      or from a `shell', `term`, or `eshell` buffer.
  9. 30 Sep, 2017 1 commit
    • Kyle Meyer's avatar
      git-rebase-mode-show-keybindings: detect translated output · 8e762d34
      Kyle Meyer authored
      Don't rely on the "Commands:" heading to detect the command section
      because this can vary depending on $LANG.  Instead detect the line for
      the first command (i.e. "p, pick").  There's no guarantee that this
      output is stable but (1) the same is true for all interactive rebase
      help output and (2) this text has not changed since the introduction
      of interactive rebase.  Also, don't assume that each command and its
      description are separated by "=" (e.g., "p, pick = use commit")
      because some translations use a different separator.
      The resulting output is a little odd in that it mixes English from
      git-rebase-command-descriptions with Git's help in $LANG.  Another
      option would be to force the entire rebase buffer to be in English by
      setting LANG/LC_ALL (e.g., in magit-rebase-interactive-1).  Until we
      decide that that's a direction we want to go, let's use this fix to
      avoid displaying inaccurate bindings in rebase buffers with translated
      Fixes #3175.
  10. 25 Jun, 2017 1 commit
  11. 29 May, 2017 2 commits
  12. 25 May, 2017 2 commits
  13. 11 Mar, 2017 1 commit
  14. 10 Feb, 2017 1 commit
    • fabacino's avatar
      Add new function `git-rebase-noop` to add a noop action at point · 0fcf73f2
      fabacino authored
      If you do a rebase and drop all the commits in the file, git will
      do nothing, because the file is considered empty (everything is
      commented). If you really do want to remove all the commits, you
      have to insert a noop action which prevents the file from being
      empty. It has no other purpose.
  15. 04 Jan, 2017 1 commit
  16. 27 Dec, 2016 1 commit
  17. 22 Dec, 2016 2 commits
  18. 14 Dec, 2016 2 commits
    • Jonas Bernoulli's avatar
      Add support for JќL key bindings · f629795f
      Jonas Bernoulli authored
      JќL is the name I have given to my (for now) personal key bindings,
      which replace "bpnf" with "jikl" for navigation (similar to how vi
      uses "hjkl", but non-modal).  Maintaining such changed key bindings
      across all the packages I use has proven to be challenging to say the
      least. Recently I have decided to try a new approach - just patch the
      packages that I use.  That might seem like bad idea, and maybe it is,
      but all the others didn't really scale either.  (And considering that
      I have written a package manager, Epkg, that is supposed to help with
      exactly this sort of thing, I ought to try that approach.)
      However for Magit patching is not feasible, because I work on that all
      the time, and sometimes when I work on a feature branch I do have to
      restart Emacs.  I need my key bindings even when I am on a feature
      branch and not by own personal key bindings branch.
      Sometimes I add some optional functionality to Magit for the benefit
      of a very small number of users, sometimes consisting of a single
      user, who manages to convince me how very important a change is, even
      though nobody else seems to have the same need.  Well, this time that
      user is me.
    • Jonas Bernoulli's avatar
      Cosmetic improvements for many keymap definitions · 441d9c87
      Jonas Bernoulli authored
      Some of the rearrangement is a bit strange. These changes prepare
      for those that come in the next commit.  Look at that if you want
      to know why some binding definitions have moved to the beginnings
      of their respective definition blocks.
  19. 20 Nov, 2016 2 commits
  20. 19 Nov, 2016 1 commit
  21. 16 Nov, 2016 1 commit
  22. 13 Oct, 2016 1 commit
  23. 09 Oct, 2016 1 commit
  24. 29 Sep, 2016 1 commit
  25. 26 Sep, 2016 2 commits
  26. 24 Sep, 2016 1 commit
  27. 18 Sep, 2016 1 commit
    • Kyle Meyer's avatar
      git-rebase: disable save check when showing commits · 7da77eeb
      Kyle Meyer authored
      The git-rebase-todo buffer is frequently in a modified state, but there
      is no need to save it before showing a commit.  It will be taken care of
      by with-editor-return when the user exits through with-editor-finish.
      The unsaved buffer should almost always be the git-rebase-todo because
      the initial 'git rebase' call will fail if there are unstaged changes.
      The user could unwisely go and modify some other tracked buffers after
      starting a rebase, and this could put things into a bad state [1], but
      this is unrelated to whether the user happened to call a command to show
      a commit.
      Closes #2770.
      [1] And, when the user has done this, I don't think there is really any
          good action to take to fix the situation.  It's bad whether or not
          the buffer is saved.  The user should just never start an
          interactive rebase and then change buffers of tracked files before
          triggering the rebase with with-editor-finish.
  28. 13 Aug, 2016 1 commit
  29. 06 Jun, 2016 1 commit
  30. 20 Apr, 2016 1 commit
  31. 31 Mar, 2016 1 commit
  32. 02 Mar, 2016 2 commits