On Fri, 18 Sep 2020 at 17:45, Andreas Grünbacher <andreas.gruenbacher@xxxxxxxxx> 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
