Re: Apply git bundle to source tree?

[Thomas Guyot-Sionnest <tguyot@gmail.com>]

On Fri, 18 Sep 2020 at 17:45, Andreas Grünbacher
<andreas.gruenbacher@gmail.com> wrote:
>
> Am Fr., 18. Sept. 2020 um 22:18 Uhr schrieb Konstantin Ryabitsev
> >
> > I know this is not what you are asking, but since you used the kernel
> > as your example, you can use the following to achieve the result
> > you're looking for:
> > curl --header 'Accept-Encoding: gzip' -L
> > https://git.kernel.org/torvalds/p/v5.9-rc1/v5.8 | gunzip - | git apply
>
> Oh, that's neat.
>
> What I had in mind were actually distro packages: most projects
> nowadays live somewhere in git repositories. When they're packaged,
> this usually results in a source package with a diff on top of a
> baseline release, so the commit history is lost. Friendly packagers
> include the commit hashes and point users to a suitable git
> repository, but that's not enforced or consistent. Including the
> actual git history in packages would be much nicer (i.e., a git
> bundle), but if that can't replace the patch as well, it's rather
> unlikely to happen.

Afaik a git bundle can do all that, and it's actually a neat idea. It
will be bigger initially than a single release, especially if the
project has not been good at keeping history tidy, but bundles could
be used for both the base release *and* patches, and actually when you
need the next version old bundles could also help downloading just the
additional bits you need.

Since you mentioned it, patches that are maintained by packagers are
best maintained in git already, so the patchset could be available in
a bundle (you can have a single bundle with multiple refs; the
release, the patchset head (each parent back to release HEAD is a
patch) or even each individual patches is that suits you). If you
maintain them as separate bundles, you will always need the release
one for the rest to become useful, but in the end it's easy to convert
between bundles and patches.

FWIW I've been using bundles since the very beginning - my use case
though was backups. I figured it was an efficient way to archive an
entire bare repo into a single file and ship it offsite. I don't think
I kept the script but it's quite simple; bundle just needs the
heads/tags - without a range it goes all the way through history. For
the restore, I would list the heads from the bundle then fetch each
back into the right head/tag in an empty repo.

--
Thomas