1. 03 Aug, 2017 8 commits
    • Jonas Bernoulli's avatar
      magit-hook-custom-get: fix commend typo · d003c3d2
      Jonas Bernoulli authored
      d003c3d2
    • Kyle Meyer's avatar
      magit-insert-modules: fixup documentation · 097eda2c
      Kyle Meyer authored
      097eda2c
    • Jonas Bernoulli's avatar
      make: use quote to help font-lock · e2888e67
      Jonas Bernoulli authored
      Help `makefile-gmake-mode' to get font-lock right by not using single
      quotes (') in elisp code blocks.  In Makefiles single quotes usually
      come in pairs around a string and that is what `makefile-gmake-mode'
      assumes, resulting in invalid font-locking.  Use `quote' instead.
      e2888e67
    • Jonas Bernoulli's avatar
      1ed9b2d0
    • Jonas Bernoulli's avatar
      magit--insert-modules-logs: expect a range as argument · ed5eec34
      Jonas Bernoulli authored
      Previously it expected a function that returns one end of the range
      (the other end always being the current branch).  Callers used to
      pass either `magit-get-push-branch' or `magit-get-upstream-ref' as
      that argument.
      
      These functions have the advantage of returning nil if the respective
      branch is not configured or does not exist, which in turn meant that
      we did not end up calling `git log ...' only to learn that that log
      is empty and then having to cancel the respective section.
      
      However calling these functions is much more expensive than calling
      `git log ...' and then possibly having to cancel.
      
      For `@{upstream}' this change is un-problematic because that always
      refers to exactly one branch or no branch at all.  The meaning of
      `@{push}' however is overloaded and can refer to multiple branches,
      or an unintended branch (for our use).
      
      As far as I can tell (see `gitrevisions(7)'), the only variable that
      affects this is `push.default', so to make sure `@{push}' works as
      expected we have to use `git -c push.default=current log ...'.
      
      Because of this issue the respective module section headings used to
      mention "<push-remote>" but now the mention "@{push}", like other
      headings mention "@{upstream}".  In this context ("show the one and
      only push target of the current branch"), we force `git' to use a
      meaningful value.  In other contexts, e.g. `git push' with no
      arguments, that would be dangerous.  Here it is not, and it is also
      not misleading because Magit never does `git push' with no arguments.
      (It is possible to do so, but users have to explicitly opt-in to that
      dangerous behavior.)
      ed5eec34
    • Jonas Bernoulli's avatar
      4c6e7cc4
    • Jonas Bernoulli's avatar
    • Jonas Bernoulli's avatar
      magit-insert-modules: new function · b92454b7
      Jonas Bernoulli authored
      b92454b7
  2. 02 Aug, 2017 2 commits
  3. 31 Jul, 2017 3 commits
  4. 30 Jul, 2017 1 commit
  5. 28 Jul, 2017 1 commit
  6. 26 Jul, 2017 1 commit
  7. 25 Jul, 2017 6 commits
  8. 23 Jul, 2017 4 commits
  9. 16 Jul, 2017 1 commit
  10. 11 Jul, 2017 5 commits
    • Jonas Bernoulli's avatar
      Merge branch 'yk/bookmark' [#3113] · 33201f76
      Jonas Bernoulli authored
      33201f76
    • Yuri Khan's avatar
      Add bookmark support [#1639] · 58474324
      Yuri Khan authored
      Theory of operation:
      
      * When the user requests a bookmark for the current buffer and it’s in
        one of the supported modes, our ‘*-make-record function’ will be
        called.
      
      * It will create a bookmark record using the default function, set its
        ‘filename’ property to the root of the current repository, ‘handler’
        to the corresponding ‘*-jump’ function, and various ‘magit-*’
        properties to parts of ‘magit-refresh-args’.
      
      * When the bookmark is activated, it is passed to its recorded handler
        function, which feeds the saved ‘magit-*’ properties into the
        relevant Magit command and restores the position in buffer.
      
      * The handler functions are marked autoload so that they pull us in
        when the user activates a bookmark even if neither ‘magit-bookmark.el’
        nor ‘magit.el’ have been loaded yet.
      
      * Otherwise, we get loaded after both ‘magit.el’ and ‘bookmark.el’ are
        loaded, which is the necessary condition for the user to start
        creating bookmarks.
      58474324
    • Kyle Meyer's avatar
      magit-log-*-re: add '\n' to complemented character alternatives · cceed770
      Kyle Meyer authored
      Prevent log regexps, which are designed to target single lines, from
      matching across lines.
      
      This avoids mis-parsing log lines like
      
          diff --git a/lisp/magit.el b/lisp/magit.el
          [...]
          3026b561 (ref)^@^@name^@1432380034^@msg
      
      If we don't exclude newlines, magit-log-heading-re matches "d" as the
      hash, "iff" up to the first NULL character as the refs, and so on.
      cceed770
    • Kyle Meyer's avatar
      magit-commit-popup: add custom reader for --reuse-message · 9eb60c0c
      Kyle Meyer authored
      As mentioned in git-reset's manpage, ORIG_HEAD can be useful for
      undoing a commit and reusing its message (though there are of course
      other ways to do this).  Define a reader for the --reuse-message
      option that offers ORIG_HEAD as the default value when it exists.
      
      Also, prompt with all ref names.  If these aren't useful for the given
      situation, the user can ignore them and enter an arbitrary value.
      
      Closes #3110.
      9eb60c0c
    • Noam Postavsky's avatar
      Use cache around magit-run-git calls · 184a26b2
      Noam Postavsky authored
      184a26b2
  11. 10 Jul, 2017 3 commits
  12. 09 Jul, 2017 4 commits
    • Kyle Meyer's avatar
      magit-read-branch: rename "default" parameter · f1cba37b
      Kyle Meyer authored
      Many magit-read-* functions take an argument for the default
      completion value that is only considered when there isn't some
      overriding default extracted from the current context (e.g., the
      branch name at point).  We call this parameter "secondary-default" in
      all other magit-read-* functions.  Use the same name here.
      f1cba37b
    • Jonas Bernoulli's avatar
      Support branch.<name.remote being an url instead of remote name · 05108e74
      Jonas Bernoulli authored
      This fixes pushing to and pulling from the upstream when the current
      branches `branch.<name.remote' is an url instead of a remote name as
      is usually the case.  Also improve information shown on the "Merge:"
      line in the status buffer.
      
      It is possible that there are other places where the use or an url as
      remote causes issues, but at least this fixes the issues mentioned in
      issue #3116.
      05108e74
    • Kyle Meyer's avatar
      magit-rev-name: treat 'refs/<subdir>/*' as a namespace · de77a75a
      Kyle Meyer authored
      Every 'git-name-rev --refs=PATTERN' instance in Magit has the
      intention of restricting the results to refs within a particular
      namespace ('refs/heads/', 'refs/remotes/', and so on).  This approach
      has false positives, though, because git-name-rev matches PATTERN
      against any part of the ref name, not only the beginning.  magit-wip's
      names are frequent offenders (e.g., 'refs/wip/wtree/refs/heads/').
      
      9ab6d554 (magit-rev-name: anchor the ref pattern by default,
      2017-06-20) eliminated these non-namespace matches by automatically
      tacking on an '--exclude=*/PATTERN', but we reverted it in b8d55867
      because the --exclude option wasn't added until Git v2.13.0.
      
      Instead let's discard git-name-rev's choice if it includes the
      namespace as a substring.  Because the substring match could result
      from a namespace repeated in the name (e.g., a terribly named
      'refs/heads/refs/heads/foo'), we only discard the name if the ref
      doesn't exist in the namespace.
      
      A downside of this approach is that there may be some other ref in the
      namespace that could be used to describe the revision, but we don't
      have access to it because git-name-rev returns only its top
      choice.  (The --exclude approach didn't have this downside.)  In the
      magit-wip context, though, this situation appears to be uncommon.
      When some commit can be named either as 'master~N' or
      'wip/wtree/refs/heads/master~M', N is usually (always?) smaller than M
      due to the way that wip refs are structured, so Git will choose
      'master~N'.
      
      Re: #3106, #3117
      de77a75a
    • Jonas Bernoulli's avatar
      Use dash alias ending with "-p" instead of the fns ending with "?" · 04e2d331
      Jonas Bernoulli authored
      The names of predicates are supposed to end with "-p" or "p" in Emacs
      Lisp.  Use `-any-p' instead of `-any?', and use `-contains-p' instead
      of `-contains?'.
      04e2d331
  13. 08 Jul, 2017 1 commit