Skip to content
Snippets Groups Projects
Select Git revision
  • pu
  • passt default
  • master
  • todo
  • next
  • maint
  • v2.8.0-rc1
  • v2.8.0-rc0
  • v2.7.2
  • v2.7.1
  • v2.7.0
  • v2.6.5
  • v2.7.0-rc3
  • v2.7.0-rc2
  • v2.7.0-rc1
  • v2.7.0-rc0
  • v2.6.4
  • v2.6.3
  • v2.6.2
  • v2.6.1
  • v2.3.10
  • v2.5.4
  • v2.4.10
  • v2.6.0
  • v2.6.0-rc3
  • v2.5.3
26 results

commit.h

  • Nguyễn Thái Ngọc Duy's avatar
    2ba33c05
    shallow.c: implement a generic shallow boundary finder based on rev-list · 2ba33c05
    Nguyễn Thái Ngọc Duy authored
    
    Instead of a custom commit walker like get_shallow_commits(), this new
    function uses rev-list to mark NOT_SHALLOW to all reachable commits,
    except borders. The definition of reachable is to be defined by the
    protocol later. This makes it more flexible to define shallow boundary.
    
    The way we find find border is paint all reachable commits NOT_SHALLOW.
    Any of them that "touches" commits without NOT_SHALLOW flag are
    considered shallow (e.g. zero parents via grafting mechanism). Shallow
    commits and their true parents are all marked SHALLOW. Then NOT_SHALLOW
    is removed from shallow commits at the end.
    
    There is an interesting observation. With a generic walker, we can
    produce all kinds of shallow cutting. In the following graph, every
    commit but "x" is reachable. "b" is a parent of "a".
    
               x -- a -- o
              /    /
        x -- c -- b -- o
    
    After this function is run, "a" and "c" are both considered shallow
    commits. After grafting occurs at the client side, what we see is
    
                    a -- o
                        /
             c -- b -- o
    
    Notice that because of grafting, "a" has zero parents, so "b" is no
    longer a parent of "a".
    
    This is unfortunate and may be solved in two ways. The first is change
    the way shallow grafting works and keep "a -- b" connection if "b"
    exists and always ends at shallow commits (iow, no loose ends). This is
    hard to detect, or at least not cheap to do.
    
    The second way is mark one "x" as shallow commit instead of "a" and
    produce this graph at client side:
    
               x -- a -- o
                   /    /
             c -- b -- o
    
    More commits, but simpler grafting rules.
    
    Signed-off-by: default avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
    Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    2ba33c05
    History
    shallow.c: implement a generic shallow boundary finder based on rev-list
    Nguyễn Thái Ngọc Duy authored
    
    Instead of a custom commit walker like get_shallow_commits(), this new
    function uses rev-list to mark NOT_SHALLOW to all reachable commits,
    except borders. The definition of reachable is to be defined by the
    protocol later. This makes it more flexible to define shallow boundary.
    
    The way we find find border is paint all reachable commits NOT_SHALLOW.
    Any of them that "touches" commits without NOT_SHALLOW flag are
    considered shallow (e.g. zero parents via grafting mechanism). Shallow
    commits and their true parents are all marked SHALLOW. Then NOT_SHALLOW
    is removed from shallow commits at the end.
    
    There is an interesting observation. With a generic walker, we can
    produce all kinds of shallow cutting. In the following graph, every
    commit but "x" is reachable. "b" is a parent of "a".
    
               x -- a -- o
              /    /
        x -- c -- b -- o
    
    After this function is run, "a" and "c" are both considered shallow
    commits. After grafting occurs at the client side, what we see is
    
                    a -- o
                        /
             c -- b -- o
    
    Notice that because of grafting, "a" has zero parents, so "b" is no
    longer a parent of "a".
    
    This is unfortunate and may be solved in two ways. The first is change
    the way shallow grafting works and keep "a -- b" connection if "b"
    exists and always ends at shallow commits (iow, no loose ends). This is
    hard to detect, or at least not cheap to do.
    
    The second way is mark one "x" as shallow commit instead of "a" and
    produce this graph at client side:
    
               x -- a -- o
                   /    /
             c -- b -- o
    
    More commits, but simpler grafting rules.
    
    Signed-off-by: default avatarNguyễn Thái Ngọc Duy <pclouds@gmail.com>
    Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>