1. 07 Apr, 2018 1 commit
  2. 11 Feb, 2018 3 commits
  3. 02 Feb, 2018 1 commit
  4. 18 Jan, 2018 2 commits
  5. 17 Jan, 2018 1 commit
  6. 16 Jan, 2018 1 commit
  7. 12 Jan, 2018 1 commit
  8. 11 Jan, 2018 2 commits
  9. 08 Jan, 2018 6 commits
  10. 07 Jan, 2018 1 commit
  11. 08 Dec, 2017 2 commits
  12. 21 Nov, 2017 1 commit
  13. 20 Nov, 2017 1 commit
    • Noam Postavsky's avatar
      Fix encoding of data and args for git subprocess on w32 · 2bb9f281
      Noam Postavsky authored
      On windows-nt systems, the arguments to subprocesses must be encoded
      in the current code-page.  But Windows git requires UTF-8 encoded
      input.  The contradictory requirements mean we can't just set
      default-process-coding-system to the right thing.  Therefore,
      explicitly encode the arguments according to `w32-ansi-code-page',
      and likewise encode input sent to git as `utf-8-unix'.
      See #3250.
  14. 14 Nov, 2017 2 commits
    • Jonas Bernoulli's avatar
      Do not claim that it is an error when the user aborts a commit · e93a063f
      Jonas Bernoulli authored
      It is an implementation detail that Git considers this user
      action to be an error, which didn't keep users from getting
      confused by it or even reporting it as a bug.
      Closes #2932.
    • Jonas Bernoulli's avatar
      Add support for not showing certain errors to user · f36ab764
      Jonas Bernoulli authored
      Instead of a single regexp try a list of regexps in order until one
      matches the output.  If that regexp has a first submatch, then use
      that as the error message as before.  If it matches but does not,
      have a first submatch, then don't show a message (later regexps are
      not tried).  When `magit-process-raise-error' is non-nil, then try
      all regexps until one has a first submatch.
      Do advertise this to users by using option because there probably
      only is a limited set of errors that should be suppressed.
  15. 09 Oct, 2017 1 commit
    • Radon Rosborough's avatar
      Handle empty credential.helper value · 4b15d582
      Radon Rosborough authored
      It is an intended use case for Git to override previously specified
      credential.helper values by providing an empty string as a new value.
      Fix the definition of `magit-credential-cache-daemon-socket' so that
      it handles this case, instead of throwing an error.
  16. 04 Oct, 2017 1 commit
    • Jonas Bernoulli's avatar
      magit-process-finish-apply-ansi-color: new variable · fb75c12c
      Jonas Bernoulli authored
      When non-nil, then run `ansi-color-apply-on-region' on the output
      after the process has finished.  For now the default is nil, and the
      variable is not advertized, because this might impact performance or
      might be unsafe.
      Re #3159.
  17. 27 Sep, 2017 1 commit
  18. 11 Jul, 2017 1 commit
  19. 09 Jul, 2017 1 commit
  20. 10 Jun, 2017 1 commit
  21. 31 May, 2017 1 commit
  22. 22 Apr, 2017 1 commit
    • Basil L. Contovounesios's avatar
      Fix process output decoding system · 513aeb2f
      Basil L. Contovounesios authored
        * Determine coding system programmatically.
        * `magit-git-output-coding-system' precedes the default coding
        * Move `magit-git-output-coding-system' from magit-process.el to
  23. 03 Apr, 2017 2 commits
  24. 17 Mar, 2017 1 commit
  25. 08 Feb, 2017 1 commit
    • Kyle Meyer's avatar
      Record the working tree for separated git directories · 439ed762
      Kyle Meyer authored
      magit-toplevel needs to determine the working tree from inside .git/
      when a buffer is visiting COMMIT_EDITMSG or various other files.  To
      do this, it uses the following logic:
       1) file is in .git/modules/<module>/: set working tree to the output
          of "git rev-parse --show-toplevel"
       2) file is in .git/worktrees/<wtree>/: set working tree to the path
          in .git/worktrees/<wtree>/gitdir, minus the trailing "/.git"
       3) file is in .git: set working tree to the parent directory
      This, however, fails when a repository was set up by passing
      --separate-git-dir to "git init" or "git clone", following step 3 to
      return an unrelated parent directory [*].
      The most visible consequence of magit-toplevel failing to return the
      working tree for separated gitdirs was that an empty diff buffer was
      displayed while committing (issue #2955).  9e0e2a24 (While committing,
      diff from inside gitdir if necessary, 2017-01-17) worked around this
      by introducing a defvar that could be let-bound to instruct
      magit-toplevel to return the gitdir instead.  This resulted in the
      diff buffer correctly showing staged changes because "git diff
      --cached" works fine from the gitdir, but it broke
      magit-diff-visit-file in these buffers (issue #2981) because the
      default directory was the git directory rather than the top-level of
      the working tree.  This approach also didn't consider other cases
      where magit-toplevel would fail inside a separated gitdir, such as
      running git-rebase-show-commit in a git-rebase-todo buffer.
      Instead, let's record the worktree -> gitdir mapping of separated
      repositories before the git call in magit-run-git-with-editor.  When
      magit-toplevel is called from a gitdir file (COMMIT_EDITMSG,
      MERGE_MSG, git-rebase-todo, ...), it can look for a working tree
      associated with the current git directory.  If one isn't found, it can
      take the parent directory as the working tree, as usual.  This comes
      at a price of a magit-toplevel and magit-git-dir call during editing
      commands, but it seems unlikely that any solution could avoid these
      This should cover all cases where Magit throws users into a buffer
      inside the git directory, making it unlikely that magit-toplevel uses
      an invalid mapping.  A user would have to call a command that involves
      magit-run-git-with-editor and then, before finishing that process, go
      to another working tree that points to the same git directory and
      again call a command that involves magit-run-git-with-editor.  And the
      user would have had to set up these working trees outside of the "git
      worktree" mechanism because magit-toplevel handles "git worktree"
      directories fine.
      Fixes #2955.
      Re: #2981.
      [*] In Git version 2.8.4 and lower, core.worktree was set when
          --separate-git-dir was used, so "git rev-parse
          --show-toplevel" (step 1) would also work for separated git
          directories.  However, it turns out that Git was not intentionally
          setting core.worktree here:
  26. 04 Jan, 2017 2 commits
  27. 27 Dec, 2016 1 commit