1. 16 Nov, 2018 1 commit
  2. 12 Nov, 2018 1 commit
  3. 11 Nov, 2018 1 commit
    • Kyle Meyer's avatar
      magit-log-merged: New command · ca5cb153
      Kyle Meyer authored
      Use git-when-merged to help users ask "When was this commit merged
      into this ref?" and "Assuming this commit was developed in a topic
      branch, what were the other commits in that topic?".
  4. 10 Nov, 2018 3 commits
  5. 09 Nov, 2018 1 commit
  6. 08 Nov, 2018 8 commits
  7. 07 Nov, 2018 1 commit
  8. 06 Nov, 2018 1 commit
  9. 04 Nov, 2018 4 commits
  10. 03 Nov, 2018 12 commits
    • Jonas Bernoulli's avatar
      git-commit-post-finish-hook: Don't run for unsafe commands · af4bf8df
      Jonas Bernoulli authored
      When a command like "git rebase --continue" used `EDITOR' to have the
      user provide a commit message and created a commit with the message it
      received that way, then it goes on doing other things that may need to
      lock the index.
      We therefore cannot run `git-commit-post-finish-hook' after the commit
      was created because otherwise there would be a race condition between
      the subprocesses of "git rebase" and whatever git commands the hook
      calls.  Blacklist commands known to keep going after committing.
      This was previously done in `magit-wip-maybe-add-commit-hook', but we
      need to prevent all of `git-commit-post-finish-hook' to be inhibited.
    • Jonas Bernoulli's avatar
      git-commit-post-finish-hook: Don't run until commit was created · d445a3d3
      Jonas Bernoulli authored
      When "emacsclient" returns, then that doesn't necessarily mean that
      "git commit", which used "emacsclient" as the `EDITOR', is already
      done creating the commit.  We do not know the pid of "git commit",
      so we have to use some other method of finding out when committing
      is complete.
      We do so by looping until "HEAD" points at another commit than it did
      before the commit was initiated.  Once that is the case we run the
      hook.  If "HEAD" still points at the same commit after one second,
      then we give up and don't run the hook.
    • Jonas Bernoulli's avatar
      magit-wip-merge-branch: Change default back to nil · 6981fc02
      Jonas Bernoulli authored
      More work is needed before this can be enabled by default.  Merging
      after committing has to be made more reliable, and log commands have
      to be improved, and it must be possible to purge old wip history.
    • Jonas Bernoulli's avatar
    • Jonas Bernoulli's avatar
    • Jonas Bernoulli's avatar
      Fix a94bc130 · 9318812e
      Jonas Bernoulli authored
    • Jonas Bernoulli's avatar
      magit-refresh: Run magit-post-commit-hook when appropriate · 2059e8d3
      Jonas Bernoulli authored
      `this-command' is always nil when that hook should be run because
      invoking the respective commands involves the server, which sets
      that value.  In this case we have to check the value `last-command'
    • Jonas Bernoulli's avatar
      magit-refresh: Fix indentation · e0f8a8c7
      Jonas Bernoulli authored
    • Jonas Bernoulli's avatar
      Do not merge into wipref when continuing a sequence · a94bc130
      Jonas Bernoulli authored
      Running a command like "git rebase --continue" can result in the user
      being asked to edit a commit message.  When the user confirms the
      message then `with-editor-post-finish-hook' is run. `magit-wip-commit'
      may be a member of that hook.
      Trying to commit to the wipref is unsafe when "git rebase" is running.
      It may result in "git rebase" failing because we hold the index.look,
      or committing failing because some child of "git rebase" does so.
      Teach `magit-wip-maybe-add-commit-hook', which is responsible for
      adding that function when appropriate, to not do so when the commit
      was initiated by a command that calls a "git" command that does other
      things after creating the commit.
    • Jonas Bernoulli's avatar
    • Jonas Bernoulli's avatar
      Restore treatment of module sections as file sections · b0b7bc7a
      Jonas Bernoulli authored
      The transition from section types to section classes and automatic
      inheritance is not complete, making these hacks necessary to restore
      some functionality that was lost when the `module' type was created.
      Deriving `magit-module-section-map' from `magit-file-section-map'
      isn't a hack, that would be necessary even if the transition were
      already complete.
    • Jonas Bernoulli's avatar
      git-commit-file-not-found: Cosmetics · f3b99797
      Jonas Bernoulli authored
  11. 01 Nov, 2018 1 commit
  12. 29 Oct, 2018 5 commits
    • Jonas Bernoulli's avatar
      magit-branch-rename: Ask before renaming on remote · 14c7b138
      Jonas Bernoulli authored
      On Github at least doing so would close an associated pull-request
      permanently.  This would be annoying if the user actually wanted to
      do the equivalent of:
        git checkout -b feature-r2 feature
        ...redo feature better...
        git branch -m feature feature-r1
        git branch -m feature-r2 feature
        git push --force origin feature feature-r1
      This happened with #3622.
    • Jonas Bernoulli's avatar
      magit-with-editor-envvar: New variable · 8506935a
      Jonas Bernoulli authored
      Setting this to `GIT_SEQUENCE_EDITOR' means that Emacs will be used to
      edit a file on behalf of `git rebase -i' but not when creating commits.
      In that case `GIT_EDITOR' (if set, else `EDITOR') will be used to edit
      commit messages and similar files.  Setting one of these env variables
      is the responsibility of the user; by setting this variable, they have
      opted out of having Magit do it for them.
      Closes #3629.
    • Kyle Meyer's avatar
      magit-reverse-files: Extend binary file check · 6cf97f5c
      Kyle Meyer authored
      The magit apply variants fail on binary files because they operate on
      diff output that exists in the buffer, and that output isn't (and
      shouldn't be) inserted with `git diff --binary'.  d0e04a14
      (magit-reverse-files: do not attempt to reverse binary files,
      2015-03-06) provided a more informative error message by checking for
      staged binary files.  Teach magit-reverse-files to also check for
      binary files when reversing files from revision and diff buffers.
      For revision mode, note that we use `diff REV^..REV' rather than
      `diff-index REV', but diff-index would be needed to match what the
      revision buffer shows for merge and root commits.  However, using
      diff-index isn't worth the added complexity.  In the case of a merge
      commit, `diff REV^..REV' would still return the correct list of binary
      files in the very rare case that a binary file shows up as a resolved
      path in a revision buffer.  In the case of a root commit, we'd fail to
      detect binary files, but this just means that we fall back to
      displaying a less informative error message in the process buffer.
      Closes #3625.
    • Kyle Meyer's avatar
      magit-staged-binary-files: Generalize and rename · d4240f5e
      Kyle Meyer authored
      This function exists so that we can detect when a user is attempting
      to perform an invalid operation on a binary file and give an
      informative error message.  To make the reverse checks more
      comprehensive, we'll need to check diffs other than the one between
      HEAD and the index.  In preparation for this, adjust
      magit-staged-binary-files to take an arbitrary list of of git-diff
    • Jonas Bernoulli's avatar
      Only merge into wipref after commit if any wip mode is enabled · fa0e336c
      Jonas Bernoulli authored
      The merging is done using `magit-wip-commit', which does more than
      just merge.  It also creates the wipref if it doesn't exist yet and
      that is clearly undesirable when the user hasn't enabled any of the
      wip modes.
  13. 27 Oct, 2018 1 commit