1. 02 Mar, 2016 1 commit
  2. 28 Feb, 2016 1 commit
  3. 23 Feb, 2016 1 commit
  4. 12 Feb, 2016 1 commit
  5. 26 Jan, 2016 3 commits
  6. 25 Jan, 2016 2 commits
    • Jonas Bernoulli's avatar
      magit-clone: no longer create symbolic-ref origin/HEAD by default · 8036f53b
      Jonas Bernoulli authored
      Actually, since `git clone' always creates that symbolic-ref,
      automatically *remove* that symbolic-ref right after cloning.
      
      The default is to remove that symbolic-ref because it isn't actually
      very useful.  Right after running `git clone' one knows which of the
      remote branches is the "remote HEAD" without having to rely on that
      symbolic-ref, because the local branch is automatically setup to use
      that as upstream.  At all other times that symbolic-ref is unreliable
      because it is not automatically updated then the "remote HEAD" changes.
      
      But some users might want it anyway, so add a new option
      `magit-clone-set-remote-head', which can be set to `t' to preserve the
      symbolic-ref.
      8036f53b
    • Jonas Bernoulli's avatar
      d6b8ea24
  7. 14 Jan, 2016 1 commit
  8. 12 Jan, 2016 1 commit
    • Jonas Bernoulli's avatar
      revert buffers using a globalized variant of auto-revert-mode · f916cd03
      Jonas Bernoulli authored
      Replace the old magit-specific auto-revert implementation with the
      mode `magit-auto-revert-mode', a globalized variant of the built-in
      `auto-revert-mode'.  By default Magit still explicitly triggers the
      reverts after running git for side-effects.  Automatic reverts are
      still enabled by default, and Magit is less verbose about it.  The
      behavior can be tuned using `magit-auto-revert-' and `auto-revert-'
      options.
      
      The main benefit of this change is that this implementation caches
      whether a file is tracked or not.  The old implementation determined
      this on every revert cycle, which did not perform well when there
      were many open buffers and/or many tracked files.
      f916cd03
  9. 05 Jan, 2016 2 commits
  10. 01 Jan, 2016 1 commit
  11. 30 Dec, 2015 1 commit
  12. 29 Dec, 2015 3 commits
  13. 23 Dec, 2015 7 commits
  14. 22 Dec, 2015 2 commits
    • Jonas Bernoulli's avatar
      magit-pull-or-fetch-popup: new popup · f6d56031
      Jonas Bernoulli authored
      Combine `magit-pull-popup' and `magit-fetch-popup' into one common
      popup.  By default the old popups are still bound in `magit-mode-map'.
      
      Add this to your init file to use the new popup:
      
        (with-eval-after-load 'magit-remote
          (define-key magit-mode-map "f" 'magit-pull-and-fetch-popup)
          (define-key magit-mode-map "F" nil))
      
      One advantage of the new popup is that it is once more possible to
      press the same key twice to fetch.  However that binding now is "f f",
      not "F F", and it fetches all remotes not just the current remote.
      
      The new popup also lacks the commands for fetching from only a single
      remote.  You can add them to the new popup by adding something like this
      to your init file:
      
        (with-eval-after-load 'magit-remote
          (magit-define-popup-action 'magit-pull-and-fetch-popup ?U
            'magit-get-upstream-branch
            'magit-fetch-from-upstream-remote ?F)
          (magit-define-popup-action 'magit-pull-and-fetch-popup ?P
            'magit-get-push-branch
            'magit-fetch-from-push-remote ?F))
      f6d56031
    • Jonas Bernoulli's avatar
      magit--push-current-to-pushremote-desc: correct description · 350863a3
      Jonas Bernoulli authored
      Previously the description contained "@{push}", which isn't precise.
      What is being pushed by the respective command is configured using
      either `branch.<name>.pushRemote' or `branch.pushDefault'.  So we
      should use "pushRemote" as the shorthand.  If these variables are
      set, then "@{push}" is usually based on their values, but when they
      are unset, then "@{push}" might be defined anyway, based on other
      variables.
      
      "@{push}" simply means "where `git push' would push to" (provided a
      single branch is being pushed), and not "the branch on the configured
      push remote we would push to".
      350863a3
  15. 21 Dec, 2015 3 commits
  16. 18 Dec, 2015 2 commits
  17. 08 Dec, 2015 4 commits
  18. 07 Dec, 2015 3 commits
  19. 06 Dec, 2015 1 commit