Re: [PATCH v5 00/40] Add initial experimental external ODB support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On 03 Aug 2017, at 10:18, Christian Couder <christian.couder@xxxxxxxxx> wrote:
> 
> ...
> 
> * The "helpers" (registered commands)
> 
> Each helper manages access to one external ODB.
> 
> There are 2 different modes for helper:
> 
>  - Helpers configured using "odb.<odbname>.scriptCommand" are
>    launched each time Git wants to communicate with the <odbname>
>    external ODB. This is called "script mode".
> 
>  - Helpers configured using "odb.<odbname>.subprocessCommand" are
>    launched launched once as a sub-process (using sub-process.h), and
>    Git communicates with them using packet lines. This is called
>    "process mode".

I am curious, why would we support two modes? Wouldn't that increase
the maintenance cost? Wouldn't the subprocess command be superior?
I imagine the script mode eases testing, right?!


> ...
> 
> These odb refs point to a blob that is stored in the Git
> repository and contain information about the blob stored in the
> external odb. This information can be specific to the external odb.
> The repos can then share this information using commands like:
> 
> `git fetch origin "refs/odbs/<odbname>/*:refs/odbs/<odbname>/*"`
> 
> At the end of the current patch series, "git clone" is teached a
> "--initial-refspec" option, that asks it to first fetch some specified
> refs. This is used in the tests to fetch the odb refs first.
> 
> This way only one "git clone" command can setup a repo using the
> external ODB mechanism as long as the right helper is installed on the
> machine and as long as the following options are used:
> 
>  - "--initial-refspec <odbrefspec>" to fetch the odb refspec
>  - "-c odb.<odbname>.command=<helper>" to configure the helper

The "odb" config could, of course, go into the global git config. 
The odbrefspec is optional, right?

I have the impression there are a number of topics on the list
that tackle the "many/big objects in a Git repo" problem. Is
there a write up about the status of them, how they relate
to each other, and what the current problems are? 
I found the following but it looks abandoned:
https://github.com/jrn/git-large-repositories

- Lars



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux