On Thu, Jun 09, 2016 at 03:53:26PM +0700, Duy Nguyen wrote:
> > Yes. To me, this was always about punting large blobs from the clones.
> > Basically the way git-lfs and other tools work, but without munging your
> > history permanently.
>
> Makes sense. If we keep all trees and commits locally, p
On Wed, Jun 8, 2016 at 11:19 PM, Jeff King wrote:
> On Wed, Jun 08, 2016 at 05:44:06PM +0700, Duy Nguyen wrote:
>
>> On Wed, Jun 8, 2016 at 3:23 AM, Jeff King wrote:
>> > Because this "external odb" essentially acts as a git alternate, we
>> > would hit it only when we couldn't find an object thr
On Wed, Jun 08, 2016 at 11:05:20AM -0700, Junio C Hamano wrote:
> > Likewise, I'm not sure if "get" should be allowed to return contents
> > that don't match the sha1.
>
> Yes, this is what I was getting at. It would be ideal to come up
> with a way to do the large-blob offload without resorting
Jeff King writes:
> This interface comes from my earlier patches, so I'll try to shed a
> little light on the decisions I made there.
>
> Because this "external odb" essentially acts as a git alternate, we
> would hit it only when we couldn't find an object through regular means.
> Git would then
On Wed, Jun 08, 2016 at 05:44:06PM +0700, Duy Nguyen wrote:
> On Wed, Jun 8, 2016 at 3:23 AM, Jeff King wrote:
> > Because this "external odb" essentially acts as a git alternate, we
> > would hit it only when we couldn't find an object through regular means.
> > Git would then make the object av
On Wed, Jun 8, 2016 at 3:23 AM, Jeff King wrote:
> Because this "external odb" essentially acts as a git alternate, we
> would hit it only when we couldn't find an object through regular means.
> Git would then make the object available in the usual on-disk format
> (probably as a loose object).
On Tue, Jun 07, 2016 at 03:19:46PM +0200, Christian Couder wrote:
> > But there are lots of cases where the server might want to tell
> > the client that don't involve bundles at all.
>
> The idea is also that anytime the server needs to send external ODB
> data to the client, it would
On Tue, Jun 07, 2016 at 12:23:40PM -0700, Junio C Hamano wrote:
> Christian Couder writes:
>
> > Git can store its objects only in the form of loose objects in
> > separate files or packed objects in a pack file.
> > To be able to better handle some kind of objects, for example big
> > blobs, it
Christian Couder writes:
> Git can store its objects only in the form of loose objects in
> separate files or packed objects in a pack file.
> To be able to better handle some kind of objects, for example big
> blobs, it would be nice if Git could store its objects in other object
> databases (OD
On Wed, Jun 1, 2016 at 3:37 PM, Duy Nguyen wrote:
> On Tue, May 31, 2016 at 8:18 PM, Christian Couder
> wrote:
I wonder if this mechanism could also be used or extended to clone and
fetch an alternate object database.
In [1], [2] and [3], and this was also discussed during the
On Wed, Jun 1, 2016 at 12:31 AM, Jeff King wrote:
> On Fri, May 20, 2016 at 02:39:06PM +0200, Christian Couder wrote:
>
>> I wonder if this mechanism could also be used or extended to clone and
>> fetch an alternate object database.
>>
>> In [1], [2] and [3], and this was also discussed during the
On Tue, Jun 7, 2016 at 3:46 PM, Christian Couder
wrote:
>> Any thought on object streaming support?
>
> No I didn't think about this. In fact I am not sure what this means.
>
>> It could be a big deal (might
>> affect some design decisions).
>
> Could you elaborate on this?
Object streaming api i
On Tue, Jun 07, 2016 at 10:46:07AM +0200, Christian Couder wrote:
> The high level overview of the patch series I would like to send
> really soon now could go like this:
>
> ---
> Git can store its objects only in the form of loose objects in
> separate files or packed objects in a pack file.
> T
On Wed, Jun 1, 2016 at 4:00 PM, Duy Nguyen wrote:
> On Tue, May 31, 2016 at 8:18 PM, Christian Couder
> wrote:
[3]
http://thread.gmane.org/gmane.comp.version-control.git/202902/focus=203020
>>>
>>> This points to https://github.com/peff/git/commits/jk/external-odb
>>> which is dead. J
On Tue, May 31, 2016 at 8:18 PM, Christian Couder
wrote:
>>> [3]
>>> http://thread.gmane.org/gmane.comp.version-control.git/202902/focus=203020
>>
>> This points to https://github.com/peff/git/commits/jk/external-odb
>> which is dead. Jeff, do you still have it somewhere, or is it not
>> worth l
On Tue, May 31, 2016 at 8:18 PM, Christian Couder
wrote:
>>> I wonder if this mechanism could also be used or extended to clone and
>>> fetch an alternate object database.
>>>
>>> In [1], [2] and [3], and this was also discussed during the
>>> Contributor Summit last month, Peff says that he start
On Fri, May 20, 2016 at 02:39:06PM +0200, Christian Couder wrote:
> I wonder if this mechanism could also be used or extended to clone and
> fetch an alternate object database.
>
> In [1], [2] and [3], and this was also discussed during the
> Contributor Summit last month, Peff says that he start
On Tue, May 31, 2016 at 07:43:27PM +0700, Duy Nguyen wrote:
> > [3]
> > http://thread.gmane.org/gmane.comp.version-control.git/202902/focus=203020
>
> This points to https://github.com/peff/git/commits/jk/external-odb
> which is dead. Jeff, do you still have it somewhere, or is it not
> worth l
On Tue, May 31, 2016 at 2:43 PM, Duy Nguyen wrote:
> On Fri, May 20, 2016 at 7:39 PM, Christian Couder
> wrote:
>> I am responding to this 2+ month old email because I am investigating
>> adding an alternate object store at the same level as loose and packed
>> objects. This alternate object stor
On Fri, May 20, 2016 at 7:39 PM, Christian Couder
wrote:
> I am responding to this 2+ month old email because I am investigating
> adding an alternate object store at the same level as loose and packed
> objects. This alternate object store could be used for large files. I
> am working on this for
I am responding to this 2+ month old email because I am investigating
adding an alternate object store at the same level as loose and packed
objects. This alternate object store could be used for large files. I
am working on this for GitLab. (Yeah, I am working, as a freelance,
for both Booking.com
On Thu, Mar 3, 2016 at 9:57 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> would it be
>> ok if we introduced a minimal resumable download service via
>> git-daemon to enable this feature with very little setup? Like
>> git-shell, you can only download certain packfiles for this use case
>>
Duy Nguyen writes:
> would it be
> ok if we introduced a minimal resumable download service via
> git-daemon to enable this feature with very little setup? Like
> git-shell, you can only download certain packfiles for this use case
> and nothing else with this service.
I think it is a matter of
On Thu, Mar 3, 2016 at 3:32 AM, Junio C Hamano wrote:
> - After arranging that packfile to be downloadable over popular
>transfer methods used for serving static files (such as HTTP or
>HTTPS) that are easily resumable as $URL/pack-$name.pack, a v3
>bundle file (call it $name.bndl) ca
The bundle v3 format introduces an ability to have the bundle header
(which describes what references in the bundled history can be
fetched, and what objects the receiving repository must have in
order to unbundle it successfully) in one file, and the bundled pack
stream data in a separate file.
A
25 matches
Mail list logo
