Tag

  • Show log

    Commit

  • Hash : 17cf36d4
    Author : Stefan Sperling
    Date : 2019-08-10T17:05:00

    changes for 0.3

  • README

  • Game of Trees (Got) is a version control system which prioritizes ease
    of use and simplicity over flexibility.
    
    Got is still under development; it is being developed exclusively
    on OpenBSD and its target audience are OpenBSD developers. Got is
    ISC-licensed and was designed with pledge(2) and unveil(2) in mind.
    
    Got uses Git repositories to store versioned data. At present, Got
    supports local version control operations only. Git can be used
    for any functionality which has not yet been implemented in Got.
    It will always remain possible to work with both Got and Git on
    the same repository.
    
    To compile the Got tool suite on OpenBSD, run:
    
     $ make obj
     $ make
     $ make install
    
    This will install the following commands:
    
     got, the command line interface
     tog, an ncurses-based interactive Git repository browser
     several helper programs from the libexec directory
     man pages (only installed if building sources from a Got release tarball)
    
    A Got release tarball will install files under /usr/local by default.
    A build started in Got's Git repository will install files under ~/bin.
    
    Tests will pass only after 'make install' because they rely on installed
    binaries in $PATH. Tests in the cmdline directory currently depend on git(1).
    
     $ doas pkg_add git
     $ make regress
    
    Man page files in the Got source tree can be viewed with 'man -l':
    
     $ man -l got/got.1
     $ man -l got/git-repository.5
     $ man -l got/got-worktree.5
     $ man -l tog/tog.1
    
    EXAMPLES in got.1 contains a quick-start guide for OpenBSD developers.
    
    
    Guidelines for reporting problems:
    
    All problem/bug reports should include a reproduction recipe in form of a
    shell script which starts out with an empty repository and runs a series of
    Got and/or Git commands to trigger the problem, be it a crash or some other
    undesirable behaviour.
    
    The regress/cmdline directory contains plenty of example scripts.
    An ideal reproduction recipe is written as an xfail ("expected failure")
    regression test. For a real-world example of an xfail test, see commits
    4866d0842a2b34812818685aaa31d3e0a966412d and
    2b496619daecc1f25b1bc0c53e01685030dc2c74 in Got's history.
    
    Please take this request very seriously; Ask for help with writing your
    regression test before asking for your problem to be fixed. Time invested
    in writing a regression test saves time wasted on back-and-forth discussion
    about how the problem can be reproduced. A regression test will need to be
    written in any case to verify a fix and prevent the problem from resurfacing.
    
    It is also possible to write test cases in C. Various examples of this
    exist in the regress/ directory. Most such tests are unit tests; it is
    unlikely that a problem found during regular usage will require a test
    to be written in C.
    
    Some areas of code, such as the tog UI, are not covered by automated tests.
    Please always try to find a way to trigger your problem via the command line
    interface before reporting a problem without a written test case included.
    If writing an automated test really turns out to be impossible, please
    explain in very clear terms how the problem can be reproduced.
    
    Mail problem reports to: Stefan Sperling <stsp@stsp.name>
    
    
    Guidelines for submitting patches:
    
    Mail patches to: Stefan Sperling <stsp@stsp.name>
    Pull requests via any Git hosting sites will likely be overlooked.
    Please keep the intended target audience in mind when contributing to Got.