Permalink
Commits on Jun 25, 2017
  1. Regenerate manuals using updated and patched Org and Ox-Texinfo+

    Please note that some of the recent changes are regressions, or have
    probably unintended consequences.  Currently it is necessary to revert
    some `org' commits and to use `ox-texinfo+'s `bleeding-edge' branch to
    build our manuals.
    
    See tarsius/ox-texinfo-plus#3.
    tarsius committed Jun 25, 2017
  2. git-rebase-line regexp did not support spaces before pick commands

    * This causes it to reject lines like "# pick ..." generated by
      magit-rebase when using git-rebase-kill-line
    Peaker committed Jun 25, 2017
Commits on Jun 21, 2017
  1. magit-branch-merge-p: both checks must succeed, not just one of them

    If a branch isn't merged into its upstream but it is merged into the
    current branch, then `magit-branch-merged-p' used to consider it to be
    merged.  But in the same situation Git does not consider the branch to
    be merged.  Adjust this function to match Git's behavior.
    
    Also remove the helper function `magit-branch-merged-into-upstream-p'.
    `magit-branch-merged-p' used to be its only caller but now it doesn't
    call it anymore.
    
    Fixes #3107.
    tarsius committed Jun 20, 2017
  2. magit-rev-name: anchor the ref pattern by default

    "git name-rev --refs=PATTERN" considers refs for which PATTERN matches
    any part of the name, not just the beginning.  However, in every
    magit-rev-name call in the current Magit code base, we're interested
    only in the refs that start with PATTERN because we want to restrict
    the refs to a particular namespace (e.g., "refs/heads/").
    
    Filter out names that include but do not start with PATTERN by
    automatically constructing an --exclude value from
    PATTERN.  (Unfortunately, prefixing PATTERN with "^" doesn't work.)
    
    This will have the most obvious effects for users of magit-wip, which
    puts its refs under namespaces like "refs/wip/wtree/refs/heads/".
    
    Re: #3106
    kyleam committed Jun 21, 2017
  3. Replace direct "git name-rev" calls with magit-rev-name

    These calls pass the same flags to "git name-rev" as magit-rev-name
    does, so let's not repeat them.  Also, the next commit will modify
    magit-rev-name to restrict the pattern match to the start of the
    string by default.  By making these function go through
    magit-rev-name, we won't need to duplicate that logic.
    kyleam committed Jun 21, 2017
  4. magit-ref-fullname: support revision suffixes

    magit-ref-ambiguous-p uses magit-ref-fullname to check if a ref is
    ambiguous, but this results in some non-ambiguous names being
    considered ambiguous because "git rev-parse --symbolic-full-name"
    doesn't handle names like master~1.
    
    We had the same problem before the introduction of
    magit-ref-ambiguous-p (7026b9b) because we used magit-ref-fullname
    directly to check whether a ref was ambiguous.  However, we only used
    this in a couple of places, and it looks like the only problematic
    case (i.e. where we passed a ref with a ^ or ~ suffix) was in
    magit-get-shortname (which led to an unnecessary "tags/" prefix for
    unambiguous tags).
    
    As of 622c994 (Merge branch 'km/show-ambig' [#3101], 2017-06-10), we
    rely on the magit-ref-fullname check (through magit-ref-ambiguous-p)
    more heavily, so the unnecessary disambiguation is more widespread and
    annoying.
    
    Instead of handling this in magit-ref-fullname, we could change
    magit-ref-ambiguous-p to strip the suffix in the name before passing
    it to magit-ref-fullname, but we handle it at this level to
    future-proof against magit-ref-fullname callers that might pass a
    revision with a suffix.
    
    Fixes #3106.
    kyleam committed Jun 20, 2017
Commits on Jun 20, 2017
  1. Regenerate manuals using updated Org and Ox-Texinfo+

    Using Org release_9.0.8-573-g4acd6c616 and Ox-Texinfo+ v1.3.0.
    
    Also stop quoting @ and { in example blocks, because `ox-texinfo'
    already does that now.
    tarsius committed Jun 20, 2017
  2. magit-show-commit: remove unnecessary magit-tag-at-point call

    As of d58dd6a (magit-branch-or-commit-at-point: also consider tag at
    point, 2016-08-03), this magit-tag-at-point call is redundant and
    unreachable.
    kyleam committed Jun 20, 2017
  3. manual: correct magit-diff-buffer-file's description

    magit-diff-buffer-file does not take a prefix argument, and it doesn't
    check whether magit-diff-arguments includes "--follow" (though "git
    diff" does actually accept an undocumented "--follow" argument).  This
    sentence appears to be a pasto from the magit-log-buffer-file entry.
    kyleam committed Jun 20, 2017
Commits on Jun 17, 2017
Commits on Jun 16, 2017
  1. magit-log-refresh-buffer: show line evolution range in header

    Note that, even though "man git-log" says that the -L argument is
    incompatible with a pathspec, we still consider -L when FILES is
    non-nil.  We do so because, if the file from the -L argument and the
    pathspec do *not* match, the output is empty, but git does not exit
    with an error.  Showing information about both the pathspec and -L
    argument in the header helps make the reason for the empty output more
    obvious.  (When the file from the -L argument and pathspec do *not*
    match, the output is the same as when no pathspec is given.)
    jguenther committed with kyleam Jun 2, 2017
  2. magit-log-buffer-file: fix `-L` arg when region is active

    Previously, the line numbers passed to `git log`'s `-L` arg were
    calculated by subtracting 1 from `line-number-at-pos` for
    `region-beginning` and `region-end`, which was incorrect.
    
    e.g. calling `mark-whole-buffer` in a file with a single line with a
    trailing newline would call `git log -L0,1:file`, instead of the
    expected `git log -L1,1:file`.
    
    This fix changes `magit-log-buffer-file` to calculate `-L` as a range
    starting at the line number at the start of the region, and ending at
    the line number at the end of the region (excluding the trailing
    newline).
    jguenther committed with kyleam May 15, 2017
Commits on Jun 13, 2017
  1. Revise donation link

    As much as I think everyone should see the hilarious Black Book lulz
    killer gif, the donation link currently 404's :-)
    ebpa committed with tarsius Jun 13, 2017
Commits on Jun 10, 2017
  1. magit-local-branch-at-point: qualify ambiguous branches

    The list returned magit-list-local-branch-names prepends "heads/" to
    branches with ambiguous refnames, so we need to do the same to the
    candidate branch.
    kyleam committed Jun 8, 2017
  2. magit-rev-branch: qualify ambiguous local branches

    When a refname in refs/tags or refs/remotes is ambgiuous,
    magit-get-shortname keeps the leading "tags/" or "remotes/".  Do the
    same for local branches.
    
    This prevents magit-show-commit from showing a tag whose name matches
    the branch that point is on.
    
    Fixes #3098.
    kyleam committed Jun 8, 2017
  3. magit-checkout: strip "heads/" from revision

    As a consequence of the previous commit, magit-read-other-branch-or-commit
    returns a qualified refname when a name is ambiguous.  While this is
    generally desirable, we don't want to pass "heads/<branch>" to "git
    checkout"; doing so would checkout the referenced commit in a detached
    state.
    kyleam committed Jun 8, 2017
  4. magit-branch-or-commit-at-point: qualify ambiguous branches and tags

    Different git commands respond differently when fed an ambiguous
    refname.  For example, "git show" will prefer the tag.  As a result,
    when a branch and a tag share the same name but point to different
    objects, running magit-show-commit with point on the branch will show
    the tag.
    kyleam committed Jun 8, 2017
  5. magit-ref-maybe-qualify: new function

    This pattern will be used in several places as we deal with ambiguous
    refname issues.
    kyleam committed Jun 8, 2017
  6. magit-ref-ambiguous-p: new function

    The primary purpose of magit-ref-fullname is to return a fully
    qualified refname, but a few places in Magit use it to check whether a
    refname is ambiguous (i.e., they don't use the fully qualified name
    that's returned).  Add a new function, magit-ref-ambiguous-p, that
    simply negates the output of magit-ref-fullname, making the intention
    of the ambiguous checks more obvious.
    kyleam committed Jun 8, 2017
  7. Break up all multi-assignment setq's

    Jonas notes: "Stefan says that the ability to set multiple variables
    is only supported for backward compatibility."
    
    #3101 (comment)
    kyleam committed Jun 9, 2017
Commits on Jun 1, 2017
  1. manual: correct the name of the "d w" command

    The command name has always been "magit-diff-working-tree", not
    "magit-diff-worktree".
    kyleam committed Jun 1, 2017
Commits on May 31, 2017
Commits on May 29, 2017