This project is mirrored from Updated .
  1. 15 Jan, 2014 2 commits
    • Junio C Hamano's avatar
      revision: propagate flag bits from tags to pointees · a7435286
      Junio C Hamano authored
      With the previous fix 895c5ba3 (revision: do not peel tags used in
      range notation, 2013-09-19), handle_revision_arg() that processes
      command line arguments for the "git log" family of commands no
      longer directly places the object pointed by the tag in the pending
      object array when it sees a tag object.  We used to place pointee
      there after copying the flag bits like UNINTERESTING and
      This change meant that any flag that is relevant to later history
      traversal must now be propagated to the pointed objects (most often
      these are commits) while starting the traversal, which is partly
      done by handle_commit() that is called from prepare_revision_walk().
      We did propagate UNINTERESTING, but did not do so for others, most
      notably SYMMETRIC_LEFT.  This caused "git log --left-right v1.0..."
      (where "v1.0" is a tag) to start losing the "leftness" from the
      commit the tag points at.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      revision: mark contents of an uninteresting tree uninteresting · 2ac5e447
      Junio C Hamano authored
      "git rev-list --objects ^A^{tree} B^{tree}" ought to mean "I want a
      list of objects inside B's tree, but please exclude the objects that
      appear inside A's tree".
      we see the top-level tree marked as uninteresting (i.e. ^A^{tree} in
      the above example) and call mark_tree_uninteresting() on it; this
      unfortunately prevents us from recursing into the tree and marking
      the objects in the tree as uninteresting.
      The reason why "git log ^A A" yields an empty set of commits,
      i.e. we do not have a similar issue for commits, is because we call
      mark_parents_uninteresting() after seeing an uninteresting commit.
      The uninteresting-ness of the commit itself does not prevent its
      parents from being marked as uninteresting.
      Introduce mark_tree_contents_uninteresting() and structure the code
      in handle_commit() in such a way that it makes it the responsibility
      of the callchain leading to this function to mark commits, trees and
      blobs as uninteresting, and also make it the responsibility of the
      helpers called from this function to mark objects that are reachable
      from them.
      Note that this is a very old bug that probably dates back to the day
      when "rev-list --objects" was introduced.  The line to clear
      tree->object.parsed at the end of mark_tree_contents_uninteresting()
      can be removed when this fix is merged to the codebase after
      6e454b9a (clear parsed flag when we free tree buffers, 2013-06-05).
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  2. 15 Oct, 2013 1 commit
    • Junio C Hamano's avatar
      revision: do not peel tags used in range notation · 895c5ba3
      Junio C Hamano authored
      A range notation "A..B" means exactly the same thing as what "^A B"
      means, i.e. the set of commits that are reachable from B but not
      from A.  But the internal representation after the revision parser
      parsed these two notations are subtly different.
       - "rev-list ^A B" leaves A and B in the revs->pending.objects[]
         array, with the former marked as UNINTERESTING and the revision
         traversal machinery propagates the mark to underlying commit
         objects A^0 and B^0.
       - "rev-list A..B" peels tags and leaves A^0 (marked as
         UNINTERESTING) and B^0 in revs->pending.objects[] array before
         the traversal machinery kicks in.
      This difference usually does not matter, but starts to matter when
      the --objects option is used.  For example, we see this:
          $ git rev-list --objects v1.8.4^1..v1.8.4 | grep $(git rev-parse v1.8.4)
          $ git rev-list --objects v1.8.4 ^v1.8.4^1 | grep $(git rev-parse v1.8.4)
          04f013dc38d7512eadb915eba22efc414f18b869 v1.8.4
      With the former invocation, the revision traversal machinery never
      hears about the tag v1.8.4 (it only sees the result of peeling it,
      i.e. the commit v1.8.4^0), and the tag itself does not appear in the
      output.  The latter does send the tag object itself to the output.
      Make the range notation keep the unpeeled objects and feed them to
      the traversal machinery to fix this inconsistency.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  3. 03 Feb, 2011 1 commit