Blob


1 Game of Trees (Got) is a version control system which prioritizes ease
2 of use and simplicity over flexibility (https://gameoftrees.org)
4 Got is still under development; it is being developed exclusively
5 on OpenBSD and its target audience are OpenBSD developers. Got is
6 ISC-licensed and was designed with pledge(2) and unveil(2) in mind.
8 Got uses Git repositories to store versioned data. At present, Got
9 supports local version control operations only. Git can be used
10 for any functionality which has not yet been implemented in Got.
11 It will always remain possible to work with both Got and Git on
12 the same repository.
14 To compile the Got client tool suite on OpenBSD, run:
16 $ make obj
17 $ make
18 $ make install
20 This will install the following commands:
22 got, the command line interface
23 tog, an ncurses-based interactive Git repository browser
24 several helper programs from the libexec directory
25 man pages (only installed if building sources from a Got release tarball)
27 A Got release tarball will install files under /usr/local by default.
28 A build started in Got's Git repository will install files under ~/bin.
30 Tests will pass only after 'make install' because they rely on installed
31 binaries in $PATH. Tests in the cmdline directory currently depend on git(1).
32 Tests which use the got clone, fetch, and send commands will fail if
33 'ssh 127.0.0.1' does not succeed non-interactively.
35 $ doas pkg_add git
36 $ make regress
38 To test with packed repositories, run:
40 $ make regress GOT_TEST_PACK=1
42 Because got unveils the /tmp directory by default using the /tmp directory
43 for test data can hide bugs. However, /tmp remains the default because
44 there is no better alternative that works out of the box. In order to
45 store test data in a directory other than /tmp, such as ~/got-test, run:
47 $ mkdir ~/got-test
48 $ make regress GOT_TEST_ROOT=~/got-test
50 Man page files in the Got source tree can be viewed with 'man -l':
52 $ man -l got/got.1
53 $ man -l got/git-repository.5
54 $ man -l got/got-worktree.5
55 $ man -l tog/tog.1
57 EXAMPLES in got.1 contains a quick-start guide for OpenBSD developers.
60 To compile the Got server tool suite on OpenBSD, run:
62 $ make obj
63 $ make server
64 $ make server-install
66 This will install the following commands:
68 gotd, the repository server program
69 gotctl, the server control utility
70 gotsh, the login shell for users accessing the server via the network
72 See the following manual page files for information about server setup:
74 $ man -l gotd/gotd.8
75 $ man -l gotd/gotd.conf.5
76 $ man -l gotctl/gotctl.8
77 $ man -l gotsh/gotsh.1
79 See regress/gotd/README for information about running the server test suite.
82 Game of Trees Web (Gotweb) is a CGI program which displays repository data
83 and is designed to work with httpd(8) and slowcgi(8). It requires the Kristaps
84 Dzonsons kcgi library, version 0.12.0 or greater.
86 To compile gotweb on OpenBSD, run:
88 # pkg_add kcgi
89 $ make web
90 # make web-install
92 This will create the following files:
93 the CGI program /var/www/cgi-bin/gotweb/gotweb
94 helper programs from the libexec directory in /var/www/cgi-bin/gotweb/libexec
95 several template files in /var/www/cgi-bin/gw_tmpl/
96 html, css, and image files in /var/www/htdocs/gotweb/
97 the directory /var/www/got/tmp/
98 man pages (only installed if building sources from a Got release tarball)
100 Documentation is available in manual pages:
102 $ man -l gotweb/gotweb.8
103 $ man -l gotweb/gotweb.conf.5
106 Got can be built with profiling enabled to debug performance issues.
107 Note that profiled builds cannot make use of pledge(2).
108 Profiling should only be enabled for one program at a time. Otherwise,
109 multiple programs will attempt to write to the 'gmon.out' file in the
110 current working directory.
112 For example, to compile got-read-pack with profiling enabled:
114 $ cd libexec/got-read-pack
115 $ make clean
116 $ make PROFILE=1
117 $ make install
119 Running any Got command which ends up using got-read-pack should now
120 produce the file 'gmon.out' in the current working directory.
121 The gprof2dot program can be used to generate a profile graph:
123 $ doas pkg_add gprof2dot graphviz
124 $ gprof ~/bin/got-read-pack gmon.out | gprof2dot | dot -T png > profile.png
126 As another example, to compile gotweb with profiling enabled:
128 $ cd gotweb
129 $ make clean
130 $ make PROFILE=1 gotweb
131 $ make # compile remaining gotweb binaries as usual
132 $ doas make install
133 $ doas chown www /var/www/cgi-bin/gotweb/
135 After loading a gotweb page in the browser, there should now
136 be a gmon.out file next to the gotweb binary:
138 $ ls -l /var/www/cgi-bin/gotweb/
139 total 6088
140 -rw-r--r-- 1 www daemon 427642 Jun 17 22:04 gmon.out
141 -rwxr-xr-x 1 www www 2630488 Jun 17 22:03 gotweb
142 drwxr-xr-x 2 root daemon 512 Jun 17 22:03 gw_tmpl
143 drwxr-xr-x 2 root daemon 512 Jun 17 22:03 libexec
146 Guidelines for reporting problems:
148 All problem/bug reports should include a reproduction recipe in form of a
149 shell script which starts out with an empty repository and runs a series of
150 Got and/or Git commands to trigger the problem, be it a crash or some other
151 undesirable behaviour.
153 The regress/cmdline directory contains plenty of example scripts.
154 An ideal reproduction recipe is written as an xfail ("expected failure")
155 regression test. For a real-world example of an xfail test, see commits
156 4866d0842a2b34812818685aaa31d3e0a966412d and
157 2b496619daecc1f25b1bc0c53e01685030dc2c74 in Got's history.
159 Please take this request very seriously; Ask for help with writing your
160 regression test before asking for your problem to be fixed. Time invested
161 in writing a regression test saves time wasted on back-and-forth discussion
162 about how the problem can be reproduced. A regression test will need to be
163 written in any case to verify a fix and prevent the problem from resurfacing.
165 It is also possible to write test cases in C. Various examples of this
166 exist in the regress/ directory. Most such tests are unit tests; it is
167 unlikely that a problem found during regular usage will require a test
168 to be written in C.
170 Some areas of code, such as the tog UI, are not covered by automated tests.
171 Please always try to find a way to trigger your problem via the command line
172 interface before reporting a problem without a written test case included.
173 If writing an automated test really turns out to be impossible, please
174 explain in very clear terms how the problem can be reproduced.
176 Mail problem reports to: gameoftrees@openbsd.org
179 Guidelines for submitting patches:
181 Mail patches to: gameoftrees@openbsd.org
182 Pull requests via any Git hosting sites will likely be overlooked.
183 Please keep the intended target audience in mind when contributing to Got.
186 Subscribing to the gameoftrees@openbsd.org mailing list:
188 The mailing list is used for patch reviews, bug reports, and user questions.
189 To subscribe, send mail to majordomo@openbsd.org with a message body of:
190 subscribe gameoftrees
192 See https://www.openbsd.org/mail.html for more information.