Skip to content
Commits on Nov 13, 2009
  1. @trast @gitster

    filter-branch: nearest-ancestor rewriting outside subdir filter

    trast committed with gitster
    Since a0e4639 (filter-branch: fix ref rewriting with
    --subdirectory-filter, 2008-08-12) git-filter-branch has done
    nearest-ancestor rewriting when using a --subdirectory-filter.
    
    However, that rewriting strategy is also a useful building block in
    other tasks.  For example, if you want to split out a subset of files
    from your history, you would typically call
    
      git filter-branch -- <refs> -- <files>
    
    But this fails for all refs that do not point directly to a commit
    that affects <files>, because their referenced commit will not be
    rewritten and the ref remains untouched.
    
    The code was already there for the --subdirectory-filter case, so just
    introduce an option that enables it independently.
    
    Signed-off-by: Thomas Rast <trast@student.ethz.ch>
    Signed-off-by: Johannes Sixt <j6t@kdbg.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @trast @gitster

    filter-branch: stop special-casing $filter_subdir argument

    trast committed with gitster
    Handling $filter_subdir in the usual way requires a separate case at
    every use, because the variable is empty when unused.
    
    Furthermore, --subdirectory-filter supplies its own '--', and if the user
    provided one himself, such as in
    
      git filter-branch --subdirectory-filter subdir -- --all -- subdir/file
    
    	an extra '--' was used as path filter in the call to git-rev-list that
    determines the commits that shall be rewritten.
    
    To keep the argument handling sane, we filter $@ to contain only the
    non-revision arguments, and store all revisions in $ref_args.  The
    $ref_args are easy to handle since only the SHA1s are needed; the
    actual branch names have already been stored in $tempdir/heads at this
    point.
    
    An extra separating -- is only required if the user did not provide
    any non-revision arguments, as the latter disambiguate the
    $filter_subdir following after them (or fail earlier because they are
    ambiguous themselves).
    
    Thanks to Johannes Sixt for suggesting this solution.
    
    Signed-off-by: Thomas Rast <trast@student.ethz.ch>
    Signed-off-by: Johannes Sixt <j6t@kdbg.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Aug 13, 2008
  1. @trast @gitster

    filter-branch: use --simplify-merges

    trast committed with gitster
    Use rev-list --simplify-merges everywhere.  This changes the behaviour
    of --subdirectory-filter in cases such as
    
      O -- A -\
       \       \
        \- B -- M
    
    where A and B bring the same changes to the subdirectory: It now keeps
    both sides of the merge.  Previously, the history would have been
    simplified to 'O -- A'.  Merges of unrelated side histories that never
    touch the subdirectory are still removed.
    
    Signed-off-by: Thomas Rast <trast@student.ethz.ch>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  2. @trast @gitster

    filter-branch: fix ref rewriting with --subdirectory-filter

    trast committed with gitster
    The previous ancestor discovery code failed on any refs that are
    (pre-rewrite) ancestors of commits marked for rewriting.  This means
    that in a situation
    
       A -- B(topic) -- C(master)
    
    where B is dropped by --subdirectory-filter pruning, the 'topic' was
    not moved up to A as intended, but left unrewritten because we asked
    about 'git rev-list ^master topic', which does not return anything.
    
    Instead, we use the straightforward
    
       git rev-list -1 $ref -- $filter_subdir
    
    to find the right ancestor.  To justify this, note that the nearest
    ancestor is unique: We use the output of
    
      git rev-list --parents -- $filter_subdir
    
    to rewrite commits in the first pass, before any ref rewriting.  If B
    is a non-merge commit, the only candidate is its parent.  If it is a
    merge, there are two cases:
    
    - All sides of the merge bring the same subdirectory contents.  Then
      rev-list already pruned away the merge in favour for just one of its
      parents, so there is only one candidate.
    
    - Some merge sides, or the merge outcome, differ.  Then the merge is
      not pruned and can be rewritten directly.
    
    So it is always safe to use rev-list -1.
    
    Signed-off-by: Thomas Rast <trast@student.ethz.ch>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commits on Aug 8, 2008
  1. @trast @gitster

    filter-branch: be more helpful when an annotated tag changes

    trast committed with gitster
    Previously, git-filter-branch failed if it attempted to update an
    annotated tag.  Now we ignore this condition if --tag-name-filter is
    given, so that we can later rewrite the tag.  If no such option was
    provided, we warn the user that he might want to run with
    "--tag-name-filter cat" to achieve the intended effect.
    
    Signed-off-by: Thomas Rast <trast@student.ethz.ch>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
Something went wrong with that request. Please try again.