Skip to content
Commits on Feb 27, 2008
  1. Merge branch 'db/cover-letter'

    * db/cover-letter:
      Improve collection of information for format-patch --cover-letter
      Add API access to shortlog
      t4014: Replace sed's non-standard 'Q' by standard 'q'
      Support a --cc=<email> option in format-patch
      Combine To: and Cc: headers
      Fix format.headers not ending with a newline
      Add tests for extra headers in format-patch
      Add a --cover-letter option to format-patch
      Export some email and pretty-printing functions
      Improve message-id generation flow control for format-patch
      Add more tests for format-patch
Commits on Feb 19, 2008
  1. Improve message-id generation flow control for format-patch

    Daniel Barkalow committed with
    Signed-off-by: Daniel Barkalow <>
    Signed-off-by: Junio C Hamano <>
Commits on Feb 13, 2008
  1. @torvalds

    Add "--show-all" revision walker flag for debugging

    torvalds committed with
    It's really not very easy to visualize the commit walker, because - on
    purpose - it obvously doesn't show the uninteresting commits!
    This adds a "--show-all" flag to the revision walker, which will make
    it show uninteresting commits too, and they'll have a '^' in front of
    them (it also fixes a logic error for !verbose_header for boundary
    commits - we should show the '-' even if left_right isn't shown).
    A separate patch to gitk to teach it the new '^' was sent
    to paulus.  With the change in place, it actually is interesting
    even for the cases that git doesn't have any problems with, ie
    for the kernel you can do:
    	gitk -d --show-all v2.6.24..
    and you see just how far down it has to parse things to see it all. The
    use of "-d" is a good idea, since the date-ordered toposort is much better
    at showing why it goes deep down (ie the date of some of those commits
    after 2.6.24 is much older, because they were merged from trees that
    weren't rebased).
    So I think this is a useful feature even for non-debugging - just to
    visualize what git does internally more.
    When it actually breaks out due to the "everybody_uninteresting()"
    case, it adds the uninteresting commits (both the one it's looking at
    now, and the list of pending ones) to the list
    This way, we really list *all* the commits we've looked at.
    Because we now end up listing commits we may not even have been parsed
    at all "show_log" and "show_commit" need to protect against commits
    that don't have a commit buffer entry.
    That second part is debatable just how it should work. Maybe we shouldn't
    show such entries at all (with this patch those entries do get shown, they
    just don't get any message shown with them). But I think this is a useful
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Dec 12, 2007
  1. shortlog: default to HEAD when the standard input is a tty

    Instead of warning the user that it is expecting git log output from
    the standard input (and waiting for the user to type the log from
    the keyboard, which is a silly thing to do), default to traverse from
    HEAD when there is no rev parameter given and the standard input is
    a tty.
    This factors out a useful helper "add_head()" from builtin-diff.c to a
    more appropriate place revision.c while renaming it to more descriptive
    name add_head_to_pending(), as that is what the function is about.
    Signed-off-by: Junio C Hamano <>
Commits on Nov 14, 2007
  1. @torvalds

    Fix parent rewriting in --early-output

    torvalds committed with
    We cannot tell a node that has been checked and found not to be
    interesting (which does not have the TREECHANGE flag) from a
    node that hasn't been checked if it is interesting or not,
    without relying on something else, such as object->parsed.
    But an object can get the "parsed" flag for other reasons.
    Which means that "TREECHANGE" has the wrong polarity.
    This changes the way how the path pruning logic marks an
    uninteresting commits.  From now on, we consider a commit
    interesting by default, and explicitly mark the ones we decided
    to prune.  The flag is renamed to "TREESAME".
    Then, this fixes the logic to show the early output with
    incomplete pruning.  It basically says "a commit that has
    TREESAME set is kind-of-UNINTERESTING", but obviously in a
    different way than an outright UNINTERESTING commit.  Until we
    parse and examine enough parents to determine if a commit
    becomes surely "kind-of-UNINTERESTING", we avoid rewriting
    the ancestry so that later rounds can fix things up.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Nov 6, 2007
  1. @torvalds

    revision walker: mini clean-up

    torvalds committed with
    This removes the unnecessary indirection of "revs->prune_fn",
    since that function is always the same one (or NULL), and there
    is in fact not even an abstraction reason to make it a function
    (i.e. its not called from some other file and doesn't allow us
    to keep the function itself static or anything like that).
    It then just replaces it with a bit that says "prune or not",
    and if not pruning, every commit gets TREECHANGE.
    That in turn means that
     - if (!revs->prune_fn || (flags & TREECHANGE))
     - if (revs->prune_fn && !(flags & TREECHANGE))
    just become
     - if (flags & TREECHANGE)
     - if (!(flags & TREECHANGE))
    Together with adding the "single_parent()" helper function, the "complex"
    conditional now becomes
    	if (!(flags & TREECHANGE) && rev->dense && single_parent(commit))
    Also indirection of "revs->dense" checking is thrown away the
    same way, because TREECHANGE bit is set appropriately now.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Nov 5, 2007
  1. @torvalds

    Enhance --early-output format

    torvalds committed with
    This makes --early-output a bit more advanced, and actually makes it
    generate multiple "Final output:" headers as it updates things
    asynchronously. I realize that the "Final output:" line is now illogical,
    since it's not really final until it also says "done", but
    It now _always_ generates a "Final output:" header in front of any commit
    list, and that output header gives you a *guess* at the maximum number of
    commits available. However, it should be noted that the guess can be
    completely off: I do a reasonable job estimating it, but it is not meant
    to be exact.
    So what happens is that you may get output like this:
     - at 0.1 seconds:
    	Final output: 2 incomplete
    	.. 2 commits listed ..
     - half a second later:
    	Final output: 33 incomplete
    	.. 33 commits listed ..
     - another half a second after that:
    	Final output: 71 incomplete
    	.. 71 commits listed ..
     - another half second later:
    	Final output: 136 incomplete
    	.. 100 commits listed: we hit the --early-output limit, and
    	.. will only output 100 commits, and after this you'll not
    	.. see an "incomplete" report any more since you got as much
    	.. early output as you asked for!
     - .. and then finally:
    	Final output: 73106 done
    	.. all the commits ..
    The above is a real-life scenario on my current kernel tree after having
    flushed all the caches.
    Tested with the experimental gitk patch that Paul sent out, and by looking
    at the actual log output (and verifying that my commit count guesses
    actually match real life fairly well).
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
Commits on Nov 4, 2007
  1. @torvalds

    Add "--early-output" log flag for interactive GUI use

    torvalds committed with
    This adds support for "--early-output[=n]" as a flag to the "git log"
    family of commands.  This allows GUI programs to state that they want to
    get some output early, in order to be able to show at least something
    quickly, even if the full output may take longer to generate.
    If no count is specified, a default count of a hundred commits will be
    used, although the actual numbr of commits output may be smaller
    depending on how many commits were actually found in the first tenth of
    a second (or if *everything* was found before that, in which case no
    early output will be provided, and only the final list is made
    When the full list is generated, there will be a "Final output:" string
    prepended to it, regardless of whether any early commits were shown or
    not, so that the consumer can always know the difference between early
    output and the final list.
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Junio C Hamano <>
  2. @torvalds

    Simplify topo-sort logic

    torvalds committed with
    .. by not using quite so much indirection.
    This currently grows the "struct commit" a bit, which could be avoided by
    using a union for "util" and "indegree" (the topo-sort used to use "util"
    anyway, so you cannot use them together), but for now the goal of this was
    to simplify, not optimize.
    Signed-off-by: Linus Torvalds <>
Commits on Aug 14, 2007
  1. @mcostalba

    Add --log-size to git log to print message size

    mcostalba committed with
    With this option git-log prints log message size
    just before the corresponding message.
    Porcelain tools could use this to speedup parsing
    of git-log output.
    Note that size refers to log message only. If also
    patch content is shown its size is not included.
    In case it is not possible to know the size upfront
    size value is set to zero.
    Signed-off-by: Marco Costalba <>
    Signed-off-by: Junio C Hamano <>
Commits on Jun 8, 2007
  1. More missing static

    Signed-off-by: Junio C Hamano <>
Commits on May 6, 2007
  1. @raalkml

    Handle return code of parse_commit in revision machinery

    raalkml committed with Junio C Hamano
    This fixes a crash in broken repositories where random commits
    suddenly disappear.
    Signed-off-by: Alex Riesen <>
    Signed-off-by: Junio C Hamano <>
Commits on Apr 26, 2007
  1. Add --date={local,relative,default}

    Junio C Hamano committed
    This adds --date={local,relative,default} option to log family of commands,
    to allow displaying timestamps in user's local timezone, relative time, or
    the default format.
    Existing --relative-date option is a synonym of --date=relative; we could
    probably deprecate it in the long run.
    Signed-off-by: Junio C Hamano <>
Commits on Apr 24, 2007
  1. store mode in rev_list, if <tree>:<filename> syntax is used

    Martin Koegler committed with Junio C Hamano
    Signed-off-by: Martin Koegler <>
    Signed-off-by: Junio C Hamano <>
Commits on Apr 12, 2007
  1. git-log --cherry-pick A...B

    Junio C Hamano committed
    This is meant to be a saner replacement for "git-cherry".
    When used with "A...B", this filters out commits whose patch
    text has the same patch-id as a commit on the other side.  It
    would probably most useful to use with --left-right.
    Signed-off-by: Junio C Hamano <>
  2. @robbat2

    Add custom subject prefix support to format-patch (take 3)

    robbat2 committed with Junio C Hamano
    Add a new option to git-format-patch, entitled --subject-prefix that allows
    control of the subject prefix '[PATCH]'. Using this option, the text 'PATCH' is
    replaced with whatever input is provided to the option. This allows easily
    generating patches like '[PATCH 2.6.21-rc3]' or properly numbered series like
    '[-mm3 PATCH N/M]'. This patch provides the implementation and documentation.
    Signed-off-by: Robin H. Johnson <>
    Signed-off-by: Junio C Hamano <>
Commits on Mar 14, 2007
  1. git-log --first-parent: show only the first parent log

    Junio C Hamano committed
    If your development history does not have fast-forward merges,
    i.e. the "first parent" of commits in your history are special
    than other parents, this option gives a better overview of the
    evolution of a particular branch.
    Signed-off-by: Junio C Hamano <>
Commits on Mar 12, 2007
  1. Merge branch 'jc/boundary'

    Junio C Hamano committed
    * jc/boundary:
      git-bundle: prevent overwriting existing bundles
      git-bundle: die if a given ref is not included in bundle
      git-bundle: handle thin packs in subcommand "unbundle"
      git-bundle: Make thin packs
      git-bundle: avoid packing objects which are in the prerequisites
      bundle: fix wrong check of read_header()'s return value & add tests
      revision --boundary: fix uncounted case.
      revision --boundary: fix stupid typo
      git-bundle: make verify a bit more chatty.
      revision traversal: SHOWN means shown
      git-bundle: various fixups
      revision traversal: retire BOUNDARY_SHOW
      revision walker: Fix --boundary when limited
Commits on Mar 6, 2007
  1. revision traversal: retire BOUNDARY_SHOW

    Junio C Hamano committed
    This removes the flag internally used by revision traversal to
    decide which commits are indeed boundaries and renames it to
    CHILD_SHOWN.  builtin-bundle uses the symbol for its
    verification, but I think the logic it uses it is wrong.  The
    flag is still useful but it is local to the git-bundle, so it is
    renamed to PREREQ_MARK.
    Signed-off-by: Junio C Hamano <>
  2. revision walker: Fix --boundary when limited

    Junio C Hamano committed
    This cleans up the boundary processing in the commit walker.  It
     - rips out the boundary logic from the commit walker. Placing
       "negative" commits in the revs->commits list was Ok if all we
       cared about "boundary" was the UNINTERESTING limiting case,
       but conceptually it was wrong.
     - makes get_revision_1() function to walk the commits and return
       the results as if there is no funny postprocessing flags such
       as --reverse, --skip nor --max-count.
     - makes get_revision() function the postprocessing phase:
       If reverse is given, wait for get_revision_1() to give
       everything that it would normally give, and then reverse it
       before consuming.
       If skip is given, skip that many before going further.
       If max is given, stop when we gave out that many.
       Now that we are about to return one positive commit, mark
       the parents of that commit to be potential boundaries
       before returning, iff we are doing the boundary processing.
       Return the commit.
     - After get_revision() finishes giving out all the positive
       commits, if we are doing the boundary processing, we look at
       the parents that we marked as potential boundaries earlier,
       see if they are really boundaries, and give them out.
    It loses more code than it adds, even when the new gc_boundary()
    function, which is purely for early optimization, is counted.
    Note that this patch is purely for eyeballing and discussion
    only.  It breaks git-bundle's verify logic because the logic
    does not use BOUNDARY_SHOW flag for its internal computation
    anymore.  After we correct it not to attempt to affect the
    boundary processing by setting the BOUNDARY_SHOW flag, we can
    remove BOUNDARY_SHOW from revision.h and use that bit assignment
    for the new CHILD_SHOWN flag.
    Signed-off-by: Junio C Hamano <>
Commits on Mar 5, 2007
  1. @dscho

    format-patch: add --inline option and make --attach a true attachment

    dscho committed with Junio C Hamano
    The existing --attach option did not create a true "attachment"
    but multipart/mixed with Content-Disposition: inline.  It should
    have been with Content-Disposition: attachment.
    Introduce --inline to add multipart/mixed that is inlined, and
    make --attach to create an attachement.
    Signed-off-by: Johannes Schindelin <>
    Signed-off-by: Junio C Hamano <>
Commits on Jan 21, 2007
  1. @dscho

    Teach revision machinery about --reverse

    dscho committed with Junio C Hamano
    The option --reverse reverses the order of the commits.
    [jc: with comments on rev_info.reverse from Simon 'corecode' Schubert.]
    Signed-off-by: Johannes Schindelin <>
    Signed-off-by: Junio C Hamano <>
  2. @dscho

    Teach the revision walker to walk by reflogs with --walk-reflogs

    dscho committed with Junio C Hamano
    When called with "--walk-reflogs", as long as there are reflogs
    available, the walker will take this information into account, rather
    than the parent information in the commit object.
    Signed-off-by: Johannes Schindelin <>
    Signed-off-by: Junio C Hamano <>
Commits on Dec 26, 2006
  1. Teach log family --encoding

    Junio C Hamano committed
    Updated commit objects record the encoding used in their
    encoding header.  This updates the log family to reencode it
    into the encoding specified in i18n.commitencoding (or the
    default, which is "utf-8") upon output.
    To force a specific encoding that is different, log family takes
    command line flag --encoding=<encoding>; giving --encoding=none
    entirely disables the reencoding and lets you view log messges
    in their original encoding.
    Signed-off-by: Junio C Hamano <>
Commits on Dec 25, 2006
  1. Merge branch 'jc/skip-count'

    Junio C Hamano committed
    * jc/skip-count:
      revision: --skip=<n>
Commits on Dec 20, 2006
  1. revision: --skip=<n>

    Junio C Hamano committed
    This adds --skip=<n> option to revision traversal machinery.
    Documentation and test were added by Robert Fitzsimons.
    Signed-off-by: Robert Fitzsimons <>
    Signed-off-by: Junio C Hamano <>
Commits on Dec 19, 2006
  1. Revert "Make left-right automatic."

    Junio C Hamano committed
    This reverts commit 5761231.
    Feeding symmetric difference to gitk is so useful, and it is the
    same for other graphical Porcelains.  Rather than forcing them
    to pass --no-left-right, making it optional.
    Noticed and reported by Jeff King.
Commits on Dec 17, 2006
  1. Make left-right automatic.

    Junio C Hamano committed
    When using symmetric differences, I think the user almost always
    would want to know which side of the symmetry each commit came
    from.  So this removes --left-right option from the command
    line, and turns it on automatically when a symmetric difference
    is used ("git log --merge" counts as a symmetric difference
    between HEAD and MERGE_HEAD).
    Just in case, a new option --no-left-right is provided to defeat
    this, but I do not know if it would be useful.
    Signed-off-by: Junio C Hamano <>
  2. Teach all of log family --left-right output.

    Junio C Hamano committed
    This makes reviewing
         git log --left-right --merge --no-merges -p
    a lot more pleasant.
    Signed-off-by: Junio C Hamano <>
  3. rev-list --left-right

    Junio C Hamano committed
    The output from "symmetric diff", i.e. A...B, does not
    distinguish between commits that are reachable from A and the
    ones that are reachable from B.  In this picture, such a
    symmetric diff includes commits marked with a and b.
             x---b---b  branch B
            / \ /
           /   .
          /   / \
         o---x---a---a  branch A
    However, you cannot tell which ones are 'a' and which ones are
    'b' from the output.  Sometimes this is frustrating.  This adds
    an output option, --left-right, to rev-list.
            rev-list --left-right A...B
    would show ones reachable from A prefixed with '<' and the ones
    reachable from B prefixed with '>'.
    When combined with --boundary, boundary commits (the ones marked
    with 'x' in the above picture) are shown with prefix '-', so you
    would see list that looks like this:
        git rev-list --left-right --boundary --pretty=oneline A...B
        >bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 3rd on b
        >bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2nd on b
        <aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 3rd on a
        <aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2nd on a
        -xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on b
        -xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on a
    Signed-off-by: Junio C Hamano <>
Commits on Sep 20, 2006
  1. git log: Unify header_filter and message_filter into one.

    Junio C Hamano committed
    Now we can tell the built-in grep to grep only in head or in
    body, use that to update --author, --committer, and --grep.
    Unfortunately, to make --and, --not and other grep boolean
    expressions useful, as in:
    	# Things written by Junio committed and by Linus and log
    	# does not talk about diff.
    	git log --author=Junio --and --committer=Linus \
    		--grep-not --grep=diff
    we will need to do another round of built-in grep core
    enhancement, because grep boolean expressions are designed to
    work on one line at a time.
    Signed-off-by: Junio C Hamano <>
  2. revision traversal: prepare for commit log match.

    Junio C Hamano committed
    This is from a suggestion by Linus, just to mark the locations where we
    need to modify to actually implement the filtering.
    We do not have any actual filtering code yet.
    Signed-off-by: Junio C Hamano <>
Commits on Sep 7, 2006
  1. pack-objects --unpacked=<existing pack> option.

    Junio C Hamano committed
    Incremental repack without -a essentially boils down to:
    	rev-list --objects --unpacked --all |
            pack-objects $new_pack
    which picks up all loose objects that are still live and creates
    a new pack.
    This implements --unpacked=<existing pack> option to tell the
    revision walking machinery to pretend as if objects in such a
    pack are unpacked for the purpose of object listing.  With this,
    we could say:
    	rev-list --objects --unpacked=$active_pack --all |
    	pack-objects $new_pack
    instead, to mean "all live loose objects but pretend as if
    objects that are in this pack are also unpacked".  The newly
    created pack would be perfect for updating $active_pack by
    replacing it.
    Since pack-objects now knows how to do the rev-list's work
    itself internally, you can also write the above example by:
    	pack-objects --unpacked=$active_pack --all $new_pack </dev/null
    Signed-off-by: Junio C Hamano <>
Commits on Sep 6, 2006
  1. revision.c: allow injecting revision parameters after setup_revisions().

    Junio C Hamano committed
    setup_revisions() wants to get all the parameters at once and
    then postprocesses the resulting revs structure after it is done
    with them.  This code structure is a bit cumbersome to deal with
    efficiently when we want to inject revision parameters from the
    side (e.g. read from standard input).
    Fortunately, the nature of this postprocessing is not affected by
    revision parameters; they are affected only by flags.  So it is
    Ok to do add_object() after the it returns.
    This splits out the code that deals with the revision parameter
    out of the main loop of setup_revisions(), so that we can later
    call it from elsewhere after it returns.
    Signed-off-by: Junio C Hamano <>
Commits on Aug 28, 2006
  1. @jonas

    Add --relative-date option to the revision interface

    jonas committed with Junio C Hamano
    Exposes the infrastructure from 9a8e35e.
    Signed-off-by: Jonas Fonseca <>
    Signed-off-by: Junio C Hamano <>
Something went wrong with that request. Please try again.