1. 17 Jan, 2018 1 commit
  2. 16 Jan, 2018 1 commit
  3. 12 Jan, 2018 1 commit
    • Kenny Ballou's avatar
      Add subject-prefix to magit-format-patch · 24ce9083
      Kenny Ballou authored
      This adds the ability to specify a subject prefix for patches created by
      the `git-format-patch` command.  Adding this ability is especially
      useful when creating versioned patch sets to be mailed.
      
      Regarding the shortcut key, I've debated either `P` or `S`.  I'm not
      aware of any other good candidates.
      Signed-off-by: default avatarKenny Ballou <kballou@devnulllabs.io>
      24ce9083
  4. 09 Jan, 2018 1 commit
  5. 07 Jan, 2018 1 commit
  6. 19 Dec, 2017 1 commit
  7. 07 Dec, 2017 1 commit
  8. 27 Nov, 2017 1 commit
    • Jonas Bernoulli's avatar
      Silence byte-compiler · 64be29ba
      Jonas Bernoulli authored
      Due to some recent change on Emacs' emacs-26 branch the byte-compiler
      started complaining that the "Lexical argument shadows the dynamic
      variable values".  That's a bit annoying - it is quite reasonable to
      have functions that take an argument named `values'.  Work around this
      by naming those arguments `values*' instead, but make sure the
      doc-strings still refer to `values'.
      64be29ba
  9. 21 Nov, 2017 4 commits
  10. 02 Nov, 2017 1 commit
    • Jonas Bernoulli's avatar
      Support one-section magit-selections · 115041d4
      Jonas Bernoulli authored
      For a long time Magit supported selecting two or more sibling sections
      using the region and then acting on that selection instead of only on
      the current section.  Single-section selections were not supported and
      a region that did not span multiple siblings was not visualized as a
      selection, instead the underlying region was visualized as it is in
      non-magit buffers.
      
      The change users will notice first is that when they press C-SPC to
      set the beginning of the region/magit-selection on a section heading,
      then the magit-selection is visualized.  Previously not even the
      region was shown after just pressing C-SPC, because the mark and the
      point were identical, so there was no non-empty region to visualize.
      
      For the time being most commands continue to behave exactly as before
      when there is a one-section selection: the act on the current section
      instead.  While a one-section selection is a selection that contains
      nothing but the current section, this difference between the current
      section and a set consisting of only the current section is still
      relevant.  It affects whether and how commands ask for confirmation
      and/or offer the user to act on something else instead.
      
      The reason I decided against supporting one-section selections in the
      past is that it is a bit unfortunate to visualize the selection and
      then the invoked command does not actually use it.  But this is no
      different from a multi-section selection being visualized and then
      invoking a command that isn't magit-selection aware at all.  Or from
      having the region visualized in any Emacs buffer and then invoking any
      command that doesn't behave differently when the region is active.
      
      Beginning with this commit only a handful of commands begin using a
      one-section selection.  Most importantly, and this is what motivated
      this change, it is now possible to use `magit-branch-spinoff' after
      selecting just HEAD to create a new branch rewinding the previously
      current branch by a single commit.  Previously it was only possible
      to rewind it to its upstream or to rewind it by at least two commits.
      
      The other commands that respect one-section selections are:
      - magit-am-apply-patches
      - magit-cherry-apply
      - magit-cherry-pick
      - magit-revert
      - magit-revert-no-commit
      - magit-stash-drop
      - magit-tag-delete
      
      The recently added commands `magit-previous-line' and
      `magit-next-line' now forgo moving on the first shift-selection move
      when point is on a section heading, not just when inside a hunk body.
      
      Closes #2920.
      Closes #3026.
      115041d4
  11. 25 Oct, 2017 1 commit
    • Kyle Meyer's avatar
      magit-format-remote*tagOpt: account for remote's length · a9177e5b
      Kyle Meyer authored
      The "remote.<name>.tagOpts" variable is not aligned with the other
      variables in the remote popup unless the remote is 6 characters (which
      is unsurprisingly the length of "origin").  Beyond the cosmetic
      alignment issue, calling magit-remote-popup when the current branch's
      remote is over 7 characters triggers an error because
      magit-popup-format-variable passes a negative length argument to
      make-string.
      
      Fix the above issues by calculating the WIDTH argument based on the
      remote's length.
      a9177e5b
  12. 20 Oct, 2017 2 commits
  13. 18 May, 2017 1 commit
    • Kyle Meyer's avatar
      magit-clone: improve suggested directory name · 41b87c67
      Kyle Meyer authored
      Extract the directory name by taking the tail of the url up to the
      first slash or colon, not the first slash or period.
      
      This makes magit-clone's default directory name match the behavior of
      "git clone <url>" in two places where it did not:
      
        1. https://[...]/foo.bar.git => "foo.bar" (instead of "bar")
      
        2. host.xz:foo/.git => "foo" (instead of "git")
      
      Fixes #3079.
      41b87c67
  14. 18 Apr, 2017 1 commit
  15. 02 Apr, 2017 1 commit
  16. 22 Mar, 2017 1 commit
  17. 12 Mar, 2017 1 commit
  18. 06 Mar, 2017 2 commits
  19. 04 Jan, 2017 1 commit
  20. 27 Dec, 2016 1 commit
  21. 22 Dec, 2016 1 commit
    • Jonas Bernoulli's avatar
      Place magit-{*}-arguments in new magit-git-arguments group · 33c5c1ca
      Jonas Bernoulli authored
      Most options named `magit-TOPIC-arguments' specify the arguments
      that are enabled by default in the respective `magit-TOPIC-popup'.
      Previously most of these options were placed in the `magit-commands'
      Custom group, which made that group rather noisy.  A few were placed
      in others group, which was inconsistent and in most cases an oversight.
      
      To avoid having to specify the group for each and every popup defined
      in Magit and in third-party extensions that share the "magit-" prefix,
      teach `magit-define-popup' to use `magit-git-arguments' if GROUP isn't
      specified and NAME does begin with "magit-".
      
      Also place `magit-git-global-arguments' into this group.  Remove it
      from `magit', but keep it in `magit-process' as before.
      33c5c1ca
  22. 11 Oct, 2016 1 commit
    • Jonas Bernoulli's avatar
      magit-push: provide better default target · 8331e3e9
      Jonas Bernoulli authored
      * When pushing a branch, then offer the push-branch as default.  Only
        if that is not set, offer the upstream as before.
      * When pushing a commit and it is reachable from HEAD, then offer to
        push to the push-remote of the current branch, or if that is not set,
        its upstream.  Closes #2820.
      8331e3e9
  23. 01 Oct, 2016 1 commit
  24. 02 Sep, 2016 1 commit
  25. 06 Jun, 2016 1 commit
  26. 14 May, 2016 1 commit
  27. 13 May, 2016 1 commit
  28. 12 May, 2016 1 commit
  29. 09 May, 2016 1 commit
    • Jonas Bernoulli's avatar
      magit-pull-from-upstream: don't explicitly specify remote branch · fd40b3a9
      Jonas Bernoulli authored
      Previously we used `git pull REMOTE BRANCH' and now we just use `git
      pull REMOTE'.  This has the advantage that tags that point to commits
      which are being pulled are also fetched.  Users have come to expect
      that behavior.
      
      We did not do this previously because I considered it to be unsafe.
      The documentation of `git push [REMOTE]' claims that it pushes to the
      upstream and fails to mention the various variables that can cause it
      to push somewhere else.  The documentation of `git pull [REMOTE]' also
      does not mention any such variables, but as the push documentation
      demonstrates, this is no guarantee that there are none.  On the other
      hand, unlike with pull, I am not actually aware of any such variables.
      
      I have decided to drop the BRANCH argument because accidentally pulling
      something different from what one wanted to pull, is much less dangerous
      than accidentally pushing to the wrong place.
      fd40b3a9
  30. 20 Apr, 2016 1 commit
  31. 25 Mar, 2016 1 commit
  32. 02 Mar, 2016 4 commits