This project is mirrored from Updated .
  1. 22 Sep, 2017 1 commit
  2. 15 Jan, 2015 1 commit
  3. 06 Aug, 2013 1 commit
  4. 12 Apr, 2013 1 commit
    • Thomas Rast's avatar
      log -L: store the path instead of a diff_filespec · 31c61918
      Thomas Rast authored
      line_log_data has held a diff_filespec* since the very early versions
      of the code.  However, the only place in the code where we actually
      need the full filespec is parse_range_arg(); in all other cases, we
      are only interested in the path, so there is hardly a reason to store
      a filespec.  Even worse, it causes a lot of redundant ->spec->path
      pointer dereferencing.
      And *even* worse, it caused the following bug.  If you merge a rename
      with a modification to the old filename, like so:
        * Merge
        | \
        |  * Modify foo
        |  |
        *  | Rename foo->bar
        | /
        * Create foo
      we internally -- in process_ranges_merge_commit() -- scan all parents.
      We are mainly looking for one that doesn't have any modifications, so
      that we can assign all the blame to it and simplify away the merge.
      In doing so, we run the normal machinery on all parents in a loop.
      For each parent, we prepare a "working set" line_log_data by making a
      copy with line_log_data_copy(), which does *not* make a copy of the
      Now suppose the rename is the first parent.  The diff machinery tells
      us that the filepair is ('foo', 'bar').  We duly update the path we
      are interested in:
        rg->spec->path = xstrdup(pair->one->path);
      But that 'struct spec' is shared between the output line_log_data and
      the original input line_log_data.  So we just wrecked the state of
      process_ranges_merge_commit().  When we get around to the second
      parent, the ranges tell us we are interested in a file 'foo' while the
      commits touch 'bar'.
      So most of this patch is just s/->spec->path/->path/ and associated
      management changes.  This implicitly fixes the bug because we removed
      the shared parts between input and output of line_log_data_copy(); it
      is now safe to overwrite the path in the copy.
      There's one only somewhat related change: the comment in
      process_all_files() explains the reasoning behind using 'range' there.
      That bit of half-correct code had me sidetracked for a while.
      Signed-off-by: default avatarThomas Rast <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  5. 28 Mar, 2013 1 commit
    • Thomas Rast's avatar
      Implement line-history search (git log -L) · 12da1d1f
      Thomas Rast authored
      This is a rewrite of much of Bo's work, mainly in an effort to split
      it into smaller, easier to understand routines.
      The algorithm is built around the struct range_set, which encodes a
      series of line ranges as intervals [a,b).  This is used in two
      * A set of lines we are tracking (which will change as we dig through
      * To encode diffs, as pairs of ranges.
      The main routine is range_set_map_across_diff().  It processes the
      diff between a commit C and some parent P.  It determines which diff
      hunks are relevant to the ranges tracked in C, and computes the new
      ranges for P.
      The algorithm is then simply to process history in topological order
      from newest to oldest, computing ranges and (partial) diffs.  At
      branch points, we need to merge the ranges we are watching.  We will
      find that many commits do not affect the chosen ranges, and mark them
      TREESAME (in addition to those already filtered by pathspec limiting).
      Another pass of history simplification then gets rid of such commits.
      This is wired as an extra filtering pass in the log machinery.  This
      currently only reduces code duplication, but should allow for other
      simplifications and options to be used.
      Finally, we hook a diff printer into the output chain.  Ideally we
      would wire directly into the diff logic, to optionally use features
      like word diff.  However, that will require some major reworking of
      the diff chain, so we completely replace the output with our own diff
      for now.
      As this was a GSoC project, and has quite some history by now, many
      people have helped.  In no particular order, thanks go to
        Jakub Narebski <[email protected]>
        Jens Lehmann <[email protected]>
        Jonathan Nieder <[email protected]>
        Junio C Hamano <[email protected]>
        Ramsay Jones <[email protected]>
        Will Palmer <[email protected]>
      Apologies to everyone I forgot.
      Signed-off-by: default avatarBo Yang <[email protected]>
      Signed-off-by: default avatarThomas Rast <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>