1. 02 Mar, 2021 1 commit
  2. 13 Jun, 2018 1 commit
  3. 05 Jun, 2018 1 commit
  4. 24 Oct, 2017 1 commit
    • Kirill Smelkov's avatar
      Relicense to GPLv3+ with wide exception for all Free Software / Open Source... · e37d99b4
      Kirill Smelkov authored
      Relicense to GPLv3+ with wide exception for all Free Software / Open Source projects + Business options.
      Nexedi stack is licensed under Free Software licenses with various exceptions
      that cover three business cases:
      - Free Software
      - Proprietary Software
      - Rebranding
      As long as one intends to develop Free Software based on Nexedi stack, no
      license cost is involved. Developing proprietary software based on Nexedi stack
      may require a proprietary exception license. Rebranding Nexedi stack is
      prohibited unless rebranding license is acquired.
      Through this licensing approach, Nexedi expects to encourage Free Software
      development without restrictions and at the same time create a framework for
      proprietary software to contribute to the long term sustainability of the
      Nexedi stack.
      Please see https://www.nexedi.com/licensing for details, rationale and options.
  5. 13 Dec, 2016 1 commit
  6. 29 Jul, 2016 1 commit
    • Kirill Smelkov's avatar
      Hook in git2go (cgo bindings to libgit2) · 624393db
      Kirill Smelkov authored
      Currently for every file -> blob, and blob -> file we invoke git
      subprocess (cat-file or hash-object). We also invoke git subprocess for
      every tag read/write and the same for commits and this 1-subprocess per
      1 object has very high overhead.
      The ways to avoid such overhead could be:
      1) for every kind of operation spawn git service process, like e.g.
         `git cat-file --batch` for reading files, and only do request/reply
         per object with it.
      2) use some go library to work with git repository ourselves.
      "1" can work but:
          - at present there is no counterpart of `cat-file --batch` for
            e.g. `hash-object` - i.e. we cannot write objects without quirks
            or patching git.
          - even if we add support for hashing via request/reply, as all
            requests are processed sequentially on git side by e.g. `git
            cat-file --batch`, we won't be able to leverage parallelism.
          - request/reply has also latency attached.
      For "2" we have roughly the following choices:
          - use cgo bindings to libgit2   (git2go)
          - use some pure-go git library
      Pure-go approach has pros that it by design avoids problems related to
      tricky CGo pointer C <-> Go passing rules. The fact that this was sorted
      out by go team itself only during 1.6 cycle
      tells a lot. The net is full of examples where those were hard to get,
      and git2go in particular has a story of e.g. heap corruption (the bug
      was on golang itself side and fixed only for 1.5)
      However there is no good (to my knowledge) pure-go git library, and the
      family of forks around github.com/speedata/gogit either:
          - works 3x slower compared to git2go
            ( or the same 3x in serial mode compared to e.g. `git cat-file --batch`
              as in serial mode git subservice and git2go has roughly similar performance )
          - or does not work at all (e.g. barfing out on REF_DELTA pack
            entries, etc)
      So because of 3x slowdown, pure-go way is currently a no-runner.
      Since one person from golang team cared to update git2go to properly
      follow the CGo rules
      we can be relatively confident about git2go bindings quality and try to
      use it.
      This commit only hooks git2go into the build, subcommands and to Sha1
      for to/from Oid conversion. We'll be switching places to git2go
      incrementally in upcoming patches.
      NOTE for now we need git2go from next branch for
      The plan is to eventually switch to
      once it is out.
  7. 06 Jul, 2016 1 commit
    • Kirill Smelkov's avatar
      Rewrite in Go · 28986e0e
      Kirill Smelkov authored
      This is more-or-less 1-to-1 port of git-backup to Go. There are things
      we handle a bit differently:
      - there is a separate type for Sha1
      - conversion of repo paths to git references is now more robust wrt
        avoiding not-allowed in git constructs like ".." or ".lock"
      The rewrite happened because we need to optimize restore, and for e.g.
      parallelizing part it should be convenient to use goroutines and channels.
      I'm not very comfortable with how error handling is done, because
      contrary to what canonical Go way seems to be, in a lot of places it still
      looks to me exceptions are better idea compared to just error codes,
      though in many places just error codes are better and makes more sense.
      Probably there will be less exceptions over time once the code starts to
      be collaborating set of goroutines with communications done via
      Still a lot of python habits on my side.
      And as a bonus we now have end-to-end pull/restore tests...