1. 28 Jan, 2017 2 commits
  2. 20 Jan, 2017 2 commits
  3. 19 Jan, 2017 5 commits
    • Jonas Bernoulli's avatar
      magit-diff-show-or-scroll: also check hash when deciding what to do · ab3a44fb
      Jonas Bernoulli authored
      When the revision or stash buffer already showed the requested
      reference, but that reference no longer pointed at the same revision,
      then the buffer was scrolled instead of updated.  Now we save the
      revision hash and compare that too.
      Fixes #2966.
    • Radon Rosborough's avatar
    • Jonas Bernoulli's avatar
      While committing, diff from inside gitdir if necessary · 9e0e2a24
      Jonas Bernoulli authored
      If a repository is created using `git init --separate-git-dir', then
      that does not set `core.worktree' (unlike what `git submodule' does).
      When committing inside such a repository `magit-commit-diff' is run
      inside the gitdir, and there is no way to prevent that.  Luckily `git
      diff' also works inside the gitdir, but because many other commands
      don't, we always run everything in the working tree.
      This is fairly deeply ingrained, so we have to add a kludge to
      `magit-toplevel', that causes it to return the gitdir instead,
      and that is triggered by dynamically binding the new variable
      `magit-toplevel--force-fallback-to-gitdir' to a non-nil value.
      And `magit-commit-diff' now does so to fix #2955.
    • Kyle Meyer's avatar
      Update release notes · e346889a
      Kyle Meyer authored
    • Kyle Meyer's avatar
      magit-log-wash-rev: don't choke on empty reflog messages · 2a268e20
      Kyle Meyer authored
      When the current branch is renamed, the entry for this event in HEAD's
      reflog has an empty message [1].  The empty message causes issues for
      magit-log-reflog-re, which will match beyond the current line to find
      the "refsub".
      As an example, the raw output
          86904ee5^@kyle Meyer^@HEAD@{1484792543 -0500}^@
          86904ee5^@kyle Meyer^@HEAD@{1484791872 -0500}^@commit (amend): msg
          c17b5061^@kyle Meyer^@HEAD@{1484791742 -0500}^@commit (amend): msg
      is washed to
          86904ee5 0
          86904ee5^@kyle   msg
          86904ee5 1  amend            msg
          c17b5061 2  amend            msg
      instead of
          86904ee5 0
          86904ee5 1  amend            msg
          c17b5061 2  amend            msg
      To handle these lines, tighten magit-log-reflog-re so that it doesn't
      allow the refsub to match newlines, and teach magit-log-wash-rev to
      insert the reflog count even when refsub has a nil value.
      Although these mostly blank lines aren't very informative, it's
      probably worth retaining them in order to be consistent with the "git
      reflog" output and to avoid users being confused about why entries are
      [1] I'm not sure if this is intentional.  I've asked the Git mailing
          list: https://public-inbox.org/git/87pojmwq5y.fsf@kyleam.com/
  4. 14 Jan, 2017 1 commit
    • Jonas Bernoulli's avatar
      Stop using cl-defun to define certain magit-get-{*} functions · 875f913b
      Jonas Bernoulli authored
      The functions `magit-get-upstream-branch' and `magit-get-push-branch'
      recently gained a second optional argument VERIFY.  That is a problem
      because the default value of the existing first argument, BRANCH, was
      defined using `cl-defun's (VAR INITFORM) format.  The value of the
      INITFORM, which is (magit-get-current-branch), is only used when the
      VAR isn't provided by the caller at all.  If the VAR is provided, but
      `nil', then that provided value `nil' is used.
      Previously it wouldn't have made much sense to use (FN nil), but now
      it is reasonable to use (FN nil t) and expect the default to be used.
      But actually one had to write (FN (magit-get-current-branch) t) until
      before this commit.
      But that clearly is very cumbersome, and so we stop using `cl-defun'
      and instead, if necessary, determine the default value inside the body
      of the affected functions.
      For consistency, we do the same thing for `magit-get-upstream-ref',
      `magit-get-upstream-remote', and `magit-get-push-remote', even though
      these functions (currently) do not take a second optional argument.
      Fixes #2960.
  5. 12 Jan, 2017 4 commits
  6. 09 Jan, 2017 1 commit
    • Alex Kost's avatar
      git-commit-setup: Call 'normal-mode' with argument · c6624d14
      Alex Kost authored
      This fixes a regression introduced by commit
      According to the docstring (and the code) of 'normal-mode', when it is
      called without argument, 'enable-local-variables' is ignored, so if
      there are unsafe local variables, a user will be prompted about them
      every time.
  7. 07 Jan, 2017 1 commit
  8. 06 Jan, 2017 1 commit
  9. 05 Jan, 2017 1 commit
  10. 04 Jan, 2017 9 commits
  11. 31 Dec, 2016 2 commits
  12. 29 Dec, 2016 7 commits
  13. 28 Dec, 2016 1 commit
    • Kyle Meyer's avatar
      magit-repolist-column-dirty: fix 801cbfd8 · 991aa241
      Kyle Meyer authored
      Despite its name, magit-unstaged-files [1] lists both staged and
      unstaged changes because it's based on a "git diff-index HEAD" call.
      As a result, magit-repolist-column-dirty's last condition in 801cbfd8
      is unreachable.  Use magit-modified-files instead, which is based on a
      "git diff-files" call and is restricted to files with unstaged
      With the above issue fixed, the last condition can be reached, but the
      return value for this condition is wrong.  Correct the
      magit-staged-files call so that "S" is returned rather than passed as
      an argument to magit-staged-files.
      [1] magit-unstaged-files was added in 65867b5d (magit-unstaged-files:
          new function, 2015-12-15) and has never been used for anything
          until its use in magit-repolist-column-dirty.  I don't know how it
          was supposed to differ from magit-modified-files.
  14. 27 Dec, 2016 3 commits