##// END OF EJS Templates
git: skeleton of a new extension to _directly_ operate on git repos...
git: skeleton of a new extension to _directly_ operate on git repos This is based in part of work I did years ago in hgit, but it's mostly new code since I'm using pygit2 instead of dulwich and the hg storage interfaces have improved. Some cleanup of old hgit code by Pulkit, which I greatly appreciate. test-git-interop.t does not cover a whole lot of cases, but it passes. It includes status, diff, making a new commit, and `hg annotate` working on the git repository. This is _not_ (yet) production quality code: this is an experiment. Known technical debt lurking in this implementation: * Writing bookmarks just totally ignores transactions. * The way progress is threaded down into the gitstore is awful. * Ideally we'd find a way to incrementally reindex DAGs. I'm not sure how to do that efficiently, so we might need a "known only fast-forwards" mode on the DAG indexer for use on `hg commit` and friends. * We don't even _try_ to do anything reasonable for `hg pull` or `hg push`. * Mercurial need an interface for the changelog type. Tests currently require git 2.24 as far as I'm aware: `git status` has some changed output that I didn't try and handle in a compatible way. This patch has produced some interesting cleanups, most recently on the manifest type. I expect continuing down this road will produce other meritorious cleanups throughout our code. Differential Revision: https://phab.mercurial-scm.org/D6734
Augie Fackler -
r44961:ad718271 default
Show More
Name Size Modified Last Commit Author
/ hgext / infinitepush
README Loading ...
__init__.py Loading ...
bundleparts.py Loading ...
common.py Loading ...
fileindexapi.py Loading ...
indexapi.py Loading ...
schema.sql Loading ...
sqlindexapi.py Loading ...
store.py Loading ...

## What is it?

This extension adds ability to save certain pushes to a remote blob store
as bundles and to serve commits from remote blob store.
The revisions are stored on disk or in everstore.
The metadata are stored in sql or on disk.

## Config options

infinitepush.branchpattern: pattern to detect a scratchbranch, example
're:scratch/.+'

infinitepush.indextype: disk or sql for the metadata
infinitepush.reponame: only relevant for sql metadata backend, reponame to put in
sql

infinitepush.indexpath: only relevant for ondisk metadata backend, the path to
store the index on disk. If not set will be under .hg
in a folder named filebundlestore

infinitepush.storepath: only relevant for ondisk metadata backend, the path to
store the bundles. If not set, it will be
.hg/filebundlestore