From: "Christian Couder" <christian.couder@xxxxxxxxx>
On Thu, Dec 7, 2017 at 7:04 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
* jh/object-filtering (2017-12-05) 9 commits
(merged to 'next' on 2017-12-05 at 3a56b51085)
+ rev-list: support --no-filter argument
+ list-objects-filter-options: support --no-filter
+ list-objects-filter-options: fix 'keword' typo in comment
(merged to 'next' on 2017-11-27 at e5008c3b28)
+ pack-objects: add list-objects filtering
+ rev-list: add list-objects filtering support
+ list-objects: filter objects in traverse_commit_list
+ oidset: add iterator methods to oidset
+ oidmap: add oidmap iterator methods
+ dir: allow exclusions from blob in addition to file
(this branch is used by jh/fsck-promisors and jh/partial-clone.)
In preparation for implementing narrow/partial clone, the object
walking machinery has been taught a way to tell it to "filter" some
objects from enumeration.
* jh/fsck-promisors (2017-12-05) 12 commits
- gc: do not repack promisor packfiles
- rev-list: support termination at promisor objects
- fixup: sha1_file: add TODO
- fixup: sha1_file: convert gotos to break/continue
- sha1_file: support lazily fetching missing objects
- introduce fetch-object: fetch one promisor object
- index-pack: refactor writing of .keep files
- fsck: support promisor objects as CLI argument
- fsck: support referenced promisor objects
- fsck: support refs pointing to promisor objects
- fsck: introduce partialclone extension
- extension.partialclone: introduce partial clone extension
(this branch is used by jh/partial-clone; uses jh/object-filtering.)
In preparation for implementing narrow/partial clone, the machinery
for checking object connectivity used by gc and fsck has been
taught that a missing object is OK when it is referenced by a
packfile specially marked as coming from trusted repository that
promises to make them available on-demand and lazily.
I am currently working on integrating this series with my external odb
series
(https://public-inbox.org/git/20170916080731.13925-1-chriscool@xxxxxxxxxxxxx/).
I too had seen that, as currently configured, the 'partialClone' could be
seen as a method for using the remote as if it were an object database (odb)
that was part of an 'always on-line' capability. However I'm cautious about
locking out the original DVCS capability of being off-line relative to some,
or all, remotes and still needing to work in 'airplane mode'.
It should be OK for the local narrowClone (my term) to be totally off-line
for a while and still be able to work when back on line with other suitable
remotes, even after the original remote has gone.
Instead of using an "extension.partialclone" config variable, an odb
will be configured like using an "odb.<odbname>.promisorRemote" (the
name might still change) config variable. Other odbs could still be
configured using "odb.<odbname>.scriptCommand" and
"odb.<odbname>.subprocessCommand".
The future work Jeff had indicated, IIRC, should be able to cope with
multiple promisor remotes, which it's to be hope this could handle. I'm not
sure how the odb code would handle a partial failure where a partition of
the odb stops being available.
The current work is still very much WIP and some tests fail, but you
can take a look there:
https://github.com/chriscool/git/tree/gl-promisor-external-odb440
--
Philip
