• J
    revision traversal: show full history with merge simplification · 6546b593
    Junio C Hamano 提交于
    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:
    
            A---M---o
           /   /
       ---O---B
    
    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:
    
       ---O---M---o
    
    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: NJunio C Hamano <gitster@pobox.com>
    6546b593
revision.h 3.8 KB