Re: [PATCH v2 4/4] bundle v3: the beginning

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,

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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.

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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,

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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]

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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. >

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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

Re: [PATCH v2 4/4] bundle v3: the beginning

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

[PATCH v2 4/4] bundle v3: the beginning

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.