1. 17 Nov, 2018 1 commit
  2. 16 Nov, 2018 3 commits
  3. 12 Nov, 2018 1 commit
  4. 11 Nov, 2018 2 commits
  5. 10 Nov, 2018 4 commits
  6. 09 Nov, 2018 1 commit
  7. 08 Nov, 2018 11 commits
  8. 07 Nov, 2018 3 commits
  9. 06 Nov, 2018 1 commit
  10. 04 Nov, 2018 4 commits
  11. 03 Nov, 2018 9 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.