git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* Supporting --depth when cloning from a bundle
@ 2022-02-16 22:07 Konstantin Ryabitsev
  2022-02-16 22:37 ` Junio C Hamano
  0 siblings, 1 reply; 4+ messages in thread
From: Konstantin Ryabitsev @ 2022-02-16 22:07 UTC (permalink / raw)
  To: git

Hello, all:

It would be pretty handy if it was possible to do shallow clones from a bundle
file. For example, this would be nice for CI environments that first download
a clone.bundle file from a locally cached location, clone from it, and then
fetch any remaining objects from remote.

E.g., in my mind this outta work:

$ wget https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/clone.bundle
$ git clone --depth 1 clone.bundle linux -b master

Right now, this operation succeeds as-is without any errors, but the resulting
git repository isn't actually shallow.

Oh, it would be even awesomer if the bundle files could be used directly with
--reference, e.g.:

$ git clone --reference clone.bundle --dissociate \
  https://git.kernel.org/.../torvalds/linux.git linux

Any reason that can't work?

-K

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Supporting --depth when cloning from a bundle
  2022-02-16 22:07 Supporting --depth when cloning from a bundle Konstantin Ryabitsev
@ 2022-02-16 22:37 ` Junio C Hamano
  2022-02-17 14:19   ` Konstantin Ryabitsev
  0 siblings, 1 reply; 4+ messages in thread
From: Junio C Hamano @ 2022-02-16 22:37 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: git

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

> Hello, all:
>
> It would be pretty handy if it was possible to do shallow clones from a bundle
> file. For example, this would be nice for CI environments that first download
> a clone.bundle file from a locally cached location, clone from it, and then
> fetch any remaining objects from remote.
>
> E.g., in my mind this outta work:
>
> $ wget https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/clone.bundle
> $ git clone --depth 1 clone.bundle linux -b master
>
> Right now, this operation succeeds as-is without any errors, but the resulting
> git repository isn't actually shallow.
>
> Oh, it would be even awesomer if the bundle files could be used directly with
> --reference, e.g.:
>
> $ git clone --reference clone.bundle --dissociate \
>   https://git.kernel.org/.../torvalds/linux.git linux
>
> Any reason that can't work?

The "depth" is used to negitiate what objects to include in the
packfile that is transmit from the other side.  That would not
fundamentally work on bundles, because a bundle is pregenerated and
there is nobody on the other side for you to negotiate with to
affect what objects are included in the packfile which is contained
in the bundle file.

You _should_ be able to make the resulting full clone into a shallow
one, though.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Supporting --depth when cloning from a bundle
  2022-02-16 22:37 ` Junio C Hamano
@ 2022-02-17 14:19   ` Konstantin Ryabitsev
  2022-02-17 21:05     ` Junio C Hamano
  0 siblings, 1 reply; 4+ messages in thread
From: Konstantin Ryabitsev @ 2022-02-17 14:19 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Wed, Feb 16, 2022 at 02:37:20PM -0800, Junio C Hamano wrote:
> The "depth" is used to negitiate what objects to include in the
> packfile that is transmit from the other side.  That would not
> fundamentally work on bundles, because a bundle is pregenerated and
> there is nobody on the other side for you to negotiate with to
> affect what objects are included in the packfile which is contained
> in the bundle file.

Junio:

Sorry for the potentially stupid follow-up question. I know that git makes a
distinction when cloning locally between a direct path and a file:// URL (e.g.
it's only possible to do a shallow clone from a local repository when using
the file:// scheme). When that happens, doesn't that same negotiation happen
locally (perhaps in a simulated way)? If that so, then theoretically the same
approach could be taken with the bundle file?

(I'm not actually that interested in that feature, to be honest -- I'd much
rather see further work on git-native CDN offload of packfiles, so we stop
using kludges like bundle files for this purpose.)

-K

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Supporting --depth when cloning from a bundle
  2022-02-17 14:19   ` Konstantin Ryabitsev
@ 2022-02-17 21:05     ` Junio C Hamano
  0 siblings, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2022-02-17 21:05 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: git

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

> Sorry for the potentially stupid follow-up question. I know that git makes a
> distinction when cloning locally between a direct path and a file:// URL (e.g.
> it's only possible to do a shallow clone from a local repository when using
> the file:// scheme).

The local optimization uses hardlinks into an existing repository
bypassing most of what makes Git Git, and there is no negotiation.

"clone --no-local $PATH" or "clone file://$PATH" runs the "server
side" inside $PATH and talks with it, which is ONLY possible because
$PATH is a real repository.  A bundle file is not a repository, and
nobody has written the "server side" to workin inside it, so...

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-02-17 21:06 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-16 22:07 Supporting --depth when cloning from a bundle Konstantin Ryabitsev
2022-02-16 22:37 ` Junio C Hamano
2022-02-17 14:19   ` Konstantin Ryabitsev
2022-02-17 21:05     ` Junio C Hamano

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).