Return to gitsofar.mdwn CVS log

Up to [NetBSD Developer Wiki] / wikisrc

start answering the core@ email about using git

    1: == NetBSD with git so far
    2: 
    3: http://mail-index.netbsd.org/tech-repository/2015/01/04/msg000497.html
    4: 
    5: === Low memory hosts:
    6: * http://mail-index.netbsd.org/tech-repository/2015/01/08/msg000520.html
    7: 
    8: git appears to have slightly different memory characteristics depending on the
    9: protocol used.  Over http I am able to get a full clone with all history on a
   10: 256 + 256 raspberri pi.  If you bump up the memory to 512 + 256 it makes ssh
   11: possible, which means writes are possible.
   12: 
   13: The link above has some tuning I used to get memory requirements way down.
   14: 
   15: It should be noted that git support a "shallow" clone (--depth 1) which ignores
   16: most history but allows commits and full development.
   17: A shallow clone works on very small systems; I would guess 128MB + a little swap
   18: is enough.
   19: 
   20: git is slow during 'status' by default since it searches the entire tree for a
   21: change.  It will produce a warning with tunable options if the command runs
   22: slowly.
   23: 
   24: === CVS in parallel
   25: I do not think this is a good idea and do not plan to advocate for it.
   26: Git does have a cvs server built-in but I have not taken the time to set it up
   27: for testing because it is slightly involved and I don't see the purpose.
   28: 
   29: === Conversion
   30: One-shot to create the new True Source.  I don't think there will be many cvs
   31: hold-outs.
   32: 
   33: See above for CVS server provided if ongoing conversion is really desired.
   34: 
   35: === existing cvs dependencies
   36: TBD
   37: 
   38: === How should NetBSD be setup
   39: High level- private box for write master using ssh, any number of additional
   40: systems with read-only mirrors over http:// and git://
   41: 
   42: Also see a great description of how DragonflyBSD is setup:
   43: http://lists.dragonflybsd.org/pipermail/users/2015-January/207421.html
   44: http://lists.dragonflybsd.org/pipermail/users/2015-January/207422.html
   45: http://lists.dragonflybsd.org/pipermail/users/2015-January/207424.html
   46: 
   47: === how to install
   48: git should fit into NetBSD src/tools easily.  I have not personally tested
   49: cross compilation.
   50: 
   51: === workflows
   52: See DragonflyBSD examples given above
   53: 
   54: There are many many workflows supported in git.  For the most part I think
   55: NetBSD developers would follow the "feature branch" workflow from the main repo
   56: (or private/semi-private clones before merge).
   57: 
   58: Public collaboration is a big feature of git since it can format patches into
   59: at least two different email formats and they can be submitted to a bug report
   60: or to a mailing list, which should allow clean apply.
   61: 
   62: A non-developer could also post a pull request to github or host his git repo
   63: for a friendly developer to add as an origin and pull his branch.
   64: 
   65: (git origin add future-developer http://example.com/~greatguy/src.git)
   66: 
   67: 
   68: === log message formats
   69: Try to references named branches instead of sha-1's
   70: Also using the dates for commits instead of commit id's
   71: 
   72: === how to convert
   73: ESR?
   74: 
   75: === No lock-in
   76: I am unable to anticipate the next generation of SCM.
   77: Don't do anything weird like change history and we should be fine.
   78: 
   79: Maybe when we have 30 years of project history it will be time to consider
   80: restructuring the project.  :)
   81: 
   82: === Who, When, and How Long?
   83: * ESR/Joerg - convert
   84: * sometime, eventually, maybe
   85: * unknown