1. 01 Oct, 2016 1 commit
  2. 02 Sep, 2016 1 commit
  3. 06 Jun, 2016 1 commit
  4. 14 May, 2016 1 commit
  5. 13 May, 2016 1 commit
  6. 12 May, 2016 1 commit
  7. 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.
  8. 20 Apr, 2016 1 commit
  9. 25 Mar, 2016 1 commit
  10. 02 Mar, 2016 4 commits
  11. 28 Feb, 2016 1 commit
  12. 23 Feb, 2016 1 commit
  13. 12 Feb, 2016 1 commit
  14. 26 Jan, 2016 3 commits
  15. 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
    • Jonas Bernoulli's avatar
  16. 14 Jan, 2016 1 commit
  17. 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-'
      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.
  18. 05 Jan, 2016 2 commits
  19. 01 Jan, 2016 1 commit
  20. 30 Dec, 2015 1 commit
  21. 29 Dec, 2015 3 commits
  22. 23 Dec, 2015 7 commits
  23. 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-fetch-from-upstream-remote ?F)
          (magit-define-popup-action 'magit-pull-and-fetch-popup ?P
            'magit-fetch-from-push-remote ?F))
    • 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
      "@{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".
  24. 21 Dec, 2015 1 commit