github.com/driusan/dgit@v0.0.0-20221118233547-f39f0c15edbb/CONTRIBUTING.md (about)

     1  # Contributing!
     2  
     3  If you'd like to contribute, I'd love to have your help, but it might help to
     4  know the code/package layout to get started.
     5  
     6  There's 3 subpackages (and a main.go) to this repo. 
     7  1. `main.go` parses the main git options, and initializes the *Client which is
     8     used throughout the code to manipulate the git repo, and calls the `cmd`
     9     package.
    10  2. `github.com/driusan/dgit/git` is a package which contains two things:
    11     abstract types that don't directly map to git command line usage (such as
    12     `type Client struct{...}` or `type File string`), and functions which implement
    13     the git command line and return values in terms of Go types. This package
    14     should be safe to use in other programs that want to interrogate/manipulate
    15     git repos in a Go-ish way without execing 'git', but isn't stable yet.
    16  3. `github.com/driusan/dgit/cmd` is a package which parses the os.Args, converts
    17     it to `package git` types, invokes the `git` package, and prints the result. It's
    18     the glue between the command line and the Go.
    19  4. zlib is a hacked up version of the standard `compress/zlib` which tries to
    20     make it possible to decompress pack files when the Reader reads too much of
    21     the file. If this doesn't make sense to you, ignore it. It doesn't matter
    22     unless you're trying to index a pack file (or decompress one without the index.)
    23  
    24  The distinction between `git` and `cmd` packages isn't as clean as it should be.
    25  (It all started off in one package, then `type Client` was moved to `git`,
    26  all the commands were moved to `cmd`, and then interdependent stuff was slowly
    27  moved around to the right package until it compiled. The refactoring of old code
    28  isn't as complete as it should be, but new code should be written with this
    29  distinction in mind.)
    30  
    31  I generally try to keep the file status.txt in the root of this repo up to date
    32  with the status of subcommands. If you'd like to contribute, a good place to
    33  start would be looking at that, taking your favourite command, and either
    34  adding missing options, or adding the command itself. If something claims to
    35  be implemented in the status.txt, you can also compare it to the official `git`
    36  client on your system and file bugs.
    37  
    38  Plumbing commands should be a higher priority than porcelain commands, and
    39  eventually the porcelain commands that exist should be re-written in terms of
    40  the underlying plumbing to be more robust.