Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Apr 27, 2012
  1. Merge branch 'cb/cherry-pick-rev-path-confusion'

    The command line parser choked "git cherry-pick $name" when $name can be
    both revision name and a pathname, even though $name can never be a path
    in the context of the command.
    The issue the patch addresses is real, but the way it is implemented felt
    unnecessarily invasive a bit.  It may be cleaner for this caller to add
    the "--" to the end of the argv_array it passes to setup_revisions().
    By Clemens Buchacher
    * cb/cherry-pick-rev-path-confusion:
      cherry-pick: do not expect file arguments
Commits on Nov 13, 2011
  1. log: --show-signature

    This teaches the "log" family of commands to pass the GPG signature in the
    commit objects to "gpg --verify" via the verify_signed_buffer() interface
    used to verify signed tag objects. E.g.
        $ git show --show-signature -s HEAD
    shows GPG output in the header part of the output.
    Signed-off-by: Junio C Hamano <>
Commits on Oct 14, 2011
  1. Merge branch 'rs/pending'

    * rs/pending:
      commit: factor out clear_commit_marks_for_object_array
      checkout: use leak_pending flag
      bundle: use leak_pending flag
      bisect: use leak_pending flag
      revision: add leak_pending flag
      checkout: use add_pending_{object,sha1} in orphan check
      revision: factor out add_pending_sha1
      checkout: check for "Previous HEAD" notice in t2020
Commits on Oct 5, 2011
  1. Merge branch 'jc/fetch-verify'

    * jc/fetch-verify:
      fetch: verify we have everything we need before updating our ref
      rev-list --verify-object
      list-objects: pass callback data to show_objects()
  2. Merge branch 'jc/traverse-commit-list'

    * jc/traverse-commit-list:
      revision.c: update show_object_with_name() without using malloc()
      revision.c: add show_object_with_name() helper function
      rev-list: fix finish_object() call
  3. Merge branch 'bk/ancestry-path'

    * bk/ancestry-path:
      t6019: avoid refname collision on case-insensitive systems
      revision: do not include sibling history in --ancestry-path output
      revision: keep track of the end-user input from the command line
      rev-list: Demonstrate breakage with --ancestry-path --all
Commits on Sep 1, 2011
  1. rev-list --verify-object

    Often we want to verify everything reachable from a given set of commits
    are present in our repository and connected without a gap to the tips of
    our refs. We used to do this for this purpose:
        $ rev-list --objects $commits_to_be_tested --not --all
    Even though this is good enough for catching missing commits and trees,
    we show the object name but do not verify their existence, let alone their
    well-formedness, for the blob objects at the leaf level.
    Add a new "--verify-object" option so that we can catch missing and broken
    blobs as well.
    Signed-off-by: Junio C Hamano <>
Commits on Aug 26, 2011
  1. revision: keep track of the end-user input from the command line

    Given a complex set of revision specifiers on the command line, it is too
    late to look at the flags of the objects in the initial traversal list at
    the beginning of limit_list() in order to determine what the objects the
    end-user explicitly listed on the command line were. The process to move
    objects from the pending array to the traversal list may have marked
    objects that are not mentioned as UNINTERESTING, when handle_commit()
    marked the parents of UNINTERESTING commits mentioned on the command line
    by calling mark_parents_uninteresting().
    This made "rev-list --ancestry-path ^A ..." to mistakenly list commits
    that are descendants of A's parents but that are not descendants of A
    itself, as ^A from the command line causes A and its parents marked as
    UNINTERESTING before coming to limit_list(), and we try to enumerate the
    commits that are descendants of these commits that are UNINTERESTING
    before we start walking the history.
    It actually is too late even if we inspected the pending object array
    before calling prepare_revision_walk(), as some of the same objects might
    have been mentioned twice, once as positive and another time as negative.
    The "rev-list --some-option A --not --all" command may want to notice,
    even if the resulting set is empty, that the user showed some interest in
    "A" and do something special about it.
    Prepare a separate array to keep track of what syntactic element was used
    to cause each object to appear in the pending array from the command line,
    and populate it as setup_revisions() parses the command line.
    Signed-off-by: Junio C Hamano <>
Commits on Aug 22, 2011
  1. revision.c: add show_object_with_name() helper function

    There are two copies of traverse_commit_list callback that show the object
    name followed by pathname the object was found, to produce output similar
    to "rev-list --objects".
    Unify them.
    Signed-off-by: Junio C Hamano <>
Commits on May 31, 2011
  1. Merge branch 'jk/format-patch-am'

    * jk/format-patch-am:
      format-patch: preserve subject newlines with -k
      clean up calling conventions for pretty.c functions
      pretty: add pp_commit_easy function for simple callers
      mailinfo: always clean up rfc822 header folding
      t: test subject handling in format-patch / am pipeline
Commits on May 30, 2011
  1. Merge branch 'jc/notes-batch-removal'

    * jc/notes-batch-removal:
      show: --ignore-missing
      notes remove: --stdin reads from the standard input
      notes remove: --ignore-missing
      notes remove: allow removing more than one
Commits on May 19, 2011
  1. show: --ignore-missing

    Instead of barfing, simply ignore bad object names seen in the
    input. This is useful when reading from "git notes list" output
    that may refer to objects that have already been garbage collected.
    Signed-off-by: Junio C Hamano <>
Commits on Mar 27, 2011
  1. Merge branch 'mg/rev-list-n-parents'

    * mg/rev-list-n-parents:
      tests: avoid nonportable {foo,bar} glob
      rev-list --min-parents,--max-parents: doc, test and completion
      revision.c: introduce --min-parents and --max-parents options
      t6009: use test_commit() from
Commits on Mar 23, 2011
  1. Merge branch 'mg/rev-list-one-side-only'

    * mg/rev-list-one-side-only:
      git-log: put space after commit mark
      t6007: test rev-list --cherry
      log --cherry: a synonym
      rev-list: documentation and test for --cherry-mark
      revision.c: introduce --cherry-mark
      rev-list/log: factor out revision mark generation
      rev-list: --left/right-only are mutually exclusive
      rev-list: documentation and test for --left/right-only
      t6007: Make sure we test --cherry-pick
      revlist.c: introduce --left/right-only for unsymmetric picking
Commits on Jun 30, 2010
  1. Merge branch 'tr/rev-list-count'

    * tr/rev-list-count:
      bash completion: Support "divergence from upstream" messages in __git_ps1
      rev-list: introduce --count option
Commits on Apr 21, 2010
  1. revision: --ancestry-path

    "rev-list A..H" computes the set of commits that are ancestors of H, but
    excludes the ones that are ancestors of A.  This is useful to see what
    happened to the history leading to H since A, in the sense that "what does
    H have that did not exist in A" (e.g. when you have a choice to update to
    H from A).
    	       x---x---A---B---C  <-- topic
    	      /			\
         x---x---x---o---o---o---o---M---D---E---F---G  <-- dev
        /						  \
       x---o---o---o---o---o---o---o---o---o---o---o---N---H  <-- master
    The result in the above example would be the commits marked with caps
    letters (except for A itself, of course), and the ones marked with 'o'.
    When you want to find out what commits in H are contaminated with the bug
    introduced by A and need fixing, however, you might want to view only the
    subset of "A..B" that are actually descendants of A, i.e. excluding the
    ones marked with 'o'.  Introduce a new option --ancestry-path to compute
    this set with "rev-list --ancestry-path A..B".
    Note that in practice, you would build a fix immediately on top of A and
    "git branch --contains A" will give the names of branches that you would
    need to merge the fix into (i.e. topic, dev and master), so this may not
    be worth paying the extra cost of postprocessing.
    Signed-off-by: Junio C Hamano <>
Commits on Mar 24, 2010
  1. Merge branch 'tr/notes-display'

    * tr/notes-display:
      git-notes(1): add a section about the meaning of history
      notes: track whether notes_trees were changed at all
      notes: add shorthand --ref to override GIT_NOTES_REF
      commit --amend: copy notes to the new commit
      rebase: support automatic notes copying
      notes: implement helpers needed for note copying during rewrite
      notes: implement 'git notes copy --stdin'
      rebase -i: invoke post-rewrite hook
      rebase: invoke post-rewrite hook
      commit --amend: invoke post-rewrite hook
      Documentation: document post-rewrite hook
      Support showing notes from more than one notes tree
      test-lib: unset GIT_NOTES_REF to stop it from influencing tests
Commits on Mar 9, 2010
  1. show -c: show patch text

    Traditionally, "show" defaulted to "show --cc" (dense combined patch), but
    asking for combined patch with "show -c" didn't turn the patch output
    format on; the placement of this logic in setup_revisions() dates back to
    cd2bdc5 (Common option parsing for "git log --diff" and friends,
    This unfortunately cannot be done as a trivial change of "if dense
    combined is asked, default to patch format" done in setup_revisions() to
    "if any combined is asked, default to patch format", as "diff-tree -c"
    needs to default to raw, while "diff-tree --cc" needs to default to patch,
    and they share the codepath.  These command specific defaults are now
    handled in the new "tweak" callback that can be customized by individual
    command implementations.
    Signed-off-by: Junio C Hamano <>
  2. revision: introduce setup_revision_opt

    So far the last parameter to setup_revisions() was to specify the default
    ref when the command line did not give any (typically "HEAD").  This changes
    it to take a pointer to a structure so that we can add other information without
    touching too many codepaths in later patches.
    There is no functionality change.
    Signed-off-by: Junio C Hamano <>
Commits on Jan 21, 2010
  1. Fix "log" family not to be too agressive about showing notes

    Giving "Notes" information in the default output format of "log" and
    "show" is a sensible progress (the user has asked for it by having the
    notes), but for some commands (e.g. "format-patch") spewing notes into the
    formatted commit log message without being asked is too aggressive.
    Enable notes output only for "log", "show", "whatchanged" by default and
    only when the user didn't ask any specific --pretty/--format from the
    command line; users can explicitly override this default with --show-notes
    and --no-notes option.
    Parts of tests are taken from Jeff King's fix.
    Signed-off-by: Jeff King <>
    Signed-off-by: Junio C Hamano <>
Commits on Nov 24, 2009
  1. Merge branch 'jc/log-stdin'

    * jc/log-stdin:
      Add trivial tests for --stdin option to log family
      Make --stdin option to "log" family read also pathspecs
      setup_revisions(): do not call get_pathspec() too early
      Teach --stdin option to "log" family
      read_revision_from_stdin(): use strbuf
Commits on Nov 20, 2009
  1. Teach --stdin option to "log" family

    Move the logic to read revs from standard input that rev-list knows about
    from it to revision machinery, so that all the users of setup_revisions()
    can feed the list of revs from the standard input when "--stdin" is used
    on the command line.
    Allow some users of the revision machinery that want different semantics
    from the "--stdin" option to disable it by setting an option in the
    rev_info structure.
    This also cleans up the kludge made to bundle.c via cut and paste.
    Signed-off-by: Junio C Hamano <>
Commits on Aug 27, 2009
  1. Merge branch 'as/maint-graph-interesting-fix'

    * as/maint-graph-interesting-fix:
      Add tests for rev-list --graph with options that simplify history
      graph API: fix bug in graph_is_interesting()
Commits on Apr 18, 2009
  1. Merge branch 'lt/pack-object-memuse'

    * lt/pack-object-memuse:
      show_object(): push path_name() call further down
      process_{tree,blob}: show objects without buffering
Commits on Apr 6, 2009
  1. Merge branch 'sb/format-patch-patchname'

    * sb/format-patch-patchname:
      format_sanitized_subject: Don't trim past initial length of strbuf
      log-tree: fix patch filename computation in "git format-patch"
      format-patch: --numbered-files and --stdout aren't mutually exclusive
      format-patch: --attach/inline uses filename instead of SHA1
      format-patch: move get_patch_filename() into log-tree
      format-patch: pass a commit to reopen_stdout()
      format-patch: construct patch filename in one function
      pretty.c: add %f format specifier to format_commit_message()
Commits on Apr 2, 2009
  1. Merge branch 'jc/maint-1.6.0-keep-pack'

    * jc/maint-1.6.0-keep-pack:
      pack-objects: don't loosen objects available in alternate or kept packs
      t7700: demonstrate repack flaw which may loosen objects unnecessarily
      Remove --kept-pack-only option and associated infrastructure
      pack-objects: only repack or loosen objects residing in "local" packs don't use --kept-pack-only option to pack-objects
      t7700-repack: add two new tests demonstrating repacking flaws
Commits on Mar 11, 2009
  1. Merge branch 'jc/maint-1.6.0-keep-pack'

    * jc/maint-1.6.0-keep-pack:
      is_kept_pack(): final clean-up
      Simplify is_kept_pack()
      Consolidate ignore_packed logic more
      has_sha1_kept_pack(): take "struct rev_info"
      has_sha1_pack(): refactor "pretend these packs do not exist" interface
      git-repack: resist stray environment variable
Commits on Feb 28, 2009
  1. is_kept_pack(): final clean-up

    Now is_kept_pack() is just a member lookup into a structure, we can write
    it as such.
    Also rewrite the sole caller of has_sha1_kept_pack() to switch on the
    criteria the callee uses (namely, revs->kept_pack_only) between calling
    has_sha1_kept_pack() and has_sha1_pack(), so that these two callees do not
    have to take a pointer to struct rev_info as an argument.
    This removes the header file dependency issue temporarily introduced by
    the earlier commit, so we revert changes associated to that as well.
    Signed-off-by: Junio C Hamano <>
  2. Simplify is_kept_pack()

    This removes --unpacked=<packfile> parameter from the revision parser, and
    rewrites its use in git-repack to pass a single --kept-pack-only option
    The new --kept-pack-only option means just that.  When this option is
    given, is_kept_pack() that used to say "not on the --unpacked=<packfile>
    list" now says "the packfile has corresponding .keep file".
    Signed-off-by: Junio C Hamano <>
  3. Consolidate ignore_packed logic more

    This refactors three loops that check if a given packfile is on the
    ignore_packed list into a function is_kept_pack().  The function returns
    false for a pack on the list, and true for a pack not on the list, because
    this list is solely used by "git repack" to pass list of packfiles that do
    not have corresponding .keep files, i.e. a packfile not on the list is
    Signed-off-by: Junio C Hamano <>
  4. has_sha1_kept_pack(): take "struct rev_info"

    Its "ignore_packed" parameter always comes from struct rev_info.  This
    patch makes the function take a pointer to the surrounding structure, so
    that the refactoring in the next patch becomes easier to review.
    There is an unfortunate header file dependency and the easiest workaround
    is to temporarily move the function declaration from cache.h to
    revision.h; this will be moved back to cache.h once the function loses
    this "ignore_packed" parameter altogether in the later part of the
    Signed-off-by: Junio C Hamano <>
Commits on Sep 19, 2008
  1. Merge branch 'tr/rev-list-reverse'

    * tr/rev-list-reverse:
      t6013: replace use of 'tac' with equivalent Perl
      rev-list: fix --reverse interaction with --parents
Commits on Sep 3, 2008
  1. Merge branch 'tr/filter-branch'

    * tr/filter-branch:
      revision --simplify-merges: make it a no-op without pathspec
      revision --simplify-merges: do not leave commits unprocessed
      revision --simplify-merges: use decoration instead of commit->util field
      Documentation: rev-list-options: move --simplify-merges documentation
      filter-branch: use --simplify-merges
      filter-branch: fix ref rewriting with --subdirectory-filter
      filter-branch: Extend test to show rewriting bug
      Topo-sort before --simplify-merges
      revision traversal: show full history with merge simplification
      revision.c: whitespace fix
Commits on Aug 14, 2008
  1. revision --simplify-merges: use decoration instead of commit->util field

    The users of revision walking machinery may want to use the util pointer
    for their own use.  Use decoration to hold the data needed during merge
    simplification instead.
    Signed-off-by: Junio C Hamano <>
Commits on Aug 2, 2008
  1. revision traversal: show full history with merge simplification

    The --full-history traversal keeps all merges in addition to non-merge
    commits that touch paths in the given pathspec.  This is useful to view
    both sides of a merge in a topology like this:
           /   /
    even when A and B makes identical change to the given paths.  The revision
    traversal without --full-history aims to come up with the simplest history
    to explain the final state of the tree, and one of the side branches can
    be pruned away.
    The behaviour to keep all merges however is inconvenient if neither A nor
    B touches the paths we are interested in.  --full-history reduces the
    topology to:
    in such a case, without removing M.
    This adds a post processing phase on top of --full-history traversal to
    remove needless merges from the resulting history.
    The idea is to compute, for each commit in the "full history" result set,
    the commit that should replace it in the simplified history.  The commit
    to replace it in the final history is determined as follows:
     * In any case, we first figure out the replacement commits of parents of
       the commit we are looking at.  The commit we are looking at is
       rewritten as if the replacement commits of its original parents are its
       parents.  While doing so, we reduce the redundant parents from the
       rewritten parent list by not just removing the identical ones, but also
       removing a parent that is an ancestor of another parent.
     * After the above parent simplification, if the commit is a root commit,
       an UNINTERESTING commit, a merge commit, or modifies the paths we are
       interested in, then the replacement commit of the commit is itself.  In
       other words, such a commit is not dropped from the final result.
    The first point above essentially means that the history is rewritten in
    the bottom up direction.  We can rewrite the parent list of a commit only
    after we know how all of its parents are rewritten.  This means that the
    processing needs to happen on the full history (i.e. after limit_list()).
    Signed-off-by: Junio C Hamano <>
Something went wrong with that request. Please try again.