A while ago there was discussion onlist about making 3.0 (git) use
git-bundle as its repository serialization format. I think that is a
great improvement from the old ad-hoc format. Attached patch implements
it.
Notes:
* I have not tried to keep compatability with old 3.0 (git) packages.
The format is experimental..
* The bundle file has a .git extension. There is no real standard for
extensions of git bundles, though .bundle is sometimes used. I choose .git
for namespace reasons. Also, a .git bundle file can be cloned just like
a .git bare repo directory.
* All tags and local branches are included in the bundle, and are restored
from the bundle. Whatever branch was checked out when the source package
was built will be the one checked out when the source package is unpacked.
* Since it clones the bundle to unpack, the bundle is set as the origin
repository. The remote git repo configuration is not preserved. (Maybe
enhance it so Vcs-Git is automatically set up as a remote?)
* All history is currently included (via the --all switch to git-bundle),
but I plan to add a format-specific dpkg-source option, to allow
filtering of what is included in the bundle.
Demo:
joey@gnu:~/src/ttyrec>cat debian/source/format
3.0 (git)
joey@gnu:~/src/ttyrec>git branch
* debian
master
upstream
joey@gnu:~/src/ttyrec>dpkg-source -b .
dpkg-source: info: using source format `3.0 (git)'
Counting objects: 204, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (99/99), done.
Writing objects: 100% (204/204), 79.94 KiB, done.
Total 204 (delta 102), reused 160 (delta 95)
dpkg-source: info: building ttyrec in ttyrec_1.0.8-4.dsc
| A while ago there was discussion onlist about making 3.0 (git) use
| git-bundle as its repository serialization format. I think that is a
| great improvement from the old ad-hoc format. Attached patch implements
| it.
You are awesome, this looks like a great improvement. (I haven't played
with it yet, but just from looking at the tty log, it looks good.)
| * All history is currently included (via the --all switch to git-bundle),
| but I plan to add a format-specific dpkg-source option, to allow
| filtering of what is included in the bundle.
Maybe allow a filter to be specified in debian/source somewhere?
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87aarend79.fsf@qurzaw.linpro.no">http://lists.debian.org/87aarend79.fsf@qurzaw.linpro.no
06-02-2010, 07:25 AM
Peter Krefting
RFC: 3.0 (git), now with bundles
Joey Hess:
A while ago there was discussion onlist about making 3.0 (git) use
git-bundle as its repository serialization format. I think that is a great
improvement from the old ad-hoc format. Attached patch implements it.
How does this interact with the actual Git repository, when it comes to
detecting patches to upstream and such? I haven't really read up on how the
format is specified, so please point me in that direction if what I am
asking is obvious.
I have some software packaged for Debian, and I usually have the upstream
master branch as master, and a debian branch with Debian changes (merging
the upstream release as they come). Or, if the upstream source is not in Git
already, a branch of imported tarballs. Or, when I am the upstream, I have
everything (including the debianization) on the master branch.
When I want to package such software, do I just clone the repository on the
correct commit and have dpkg handle it? Does it still need the upstream
tarball, or will the entire source be reconstructed from the git archive?
--
// Peter - http://www.softwolves.pp.se/
--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: alpine.DEB.2.00.1006020821200.23247@ds9.cixit.se"> http://lists.debian.org/alpine.DEB.2.00.1006020821200.23247@ds9.cixit.se
06-02-2010, 03:41 PM
Joey Hess
RFC: 3.0 (git), now with bundles
Peter Krefting wrote:
> How does this interact with the actual Git repository, when it comes
> to detecting patches to upstream and such? I haven't really read up
> on how the format is specified, so please point me in that direction
> if what I am asking is obvious.
It *is* the actual git repository, in basically all respects.
> I have some software packaged for Debian, and I usually have the
> upstream master branch as master, and a debian branch with Debian
> changes (merging the upstream release as they come). Or, if the
> upstream source is not in Git already, a branch of imported
> tarballs. Or, when I am the upstream, I have everything (including
> the debianization) on the master branch.
>
> When I want to package such software, do I just clone the repository
> on the correct commit and have dpkg handle it? Does it still need
> the upstream tarball, or will the entire source be reconstructed
> from the git archive?
You checkout the debian branch or whatever branch you have the
debianization on, and build the package from there.
(You may use pristine-tar to store the upstream tarball in the git repo
if desired, but this is not strictly necessary.)
--
see shy jo
06-02-2010, 03:43 PM
Joey Hess
RFC: 3.0 (git), now with bundles
Tollef Fog Heen wrote:
> | * All history is currently included (via the --all switch to git-bundle),
> | but I plan to add a format-specific dpkg-source option, to allow
> | filtering of what is included in the bundle.
>
> Maybe allow a filter to be specified in debian/source somewhere?
It should be possible to use debian/source/options to specify such
options. (Or debian/source/local-options)
--
see shy jo
06-02-2010, 08:15 PM
Joey Hess
RFC: 3.0 (git), now with bundles
Attached updated patch adds the ability to limit the history depth that
is included in the git bundle (via --git-depth), as well as fully
control which tags/branches/objects are included/excluded in the bundle
(via --git-ref).
A new .gitshallow file is added to the source package to record info
git needs for shallow clones.
Note that in this example, 4 revs of mytag were stored, because git
clone --depth always stores one more rev than requested. 5 revs of the
debian branch were stored, because it shares history with mytag. The
debian/source/options caused all other tags and branches to be omitted,
so their history is not included.
--
see shy jo
07-25-2010, 02:59 PM
Raphael Hertzog
RFC: 3.0 (git), now with bundles
Hi,
On Wed, 02 Jun 2010, Joey Hess wrote:
> Attached updated patch adds the ability to limit the history depth that
> is included in the git bundle (via --git-depth), as well as fully
> control which tags/branches/objects are included/excluded in the bundle
> (via --git-ref).
I've committed your patch with a few cleanups (coding style mainly) and will
push it later today. It will thus be in the next upload (1.15.8).
Follow my Debian News â–¶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100725145914.GA5776@rivendell">http://lists.debian.org/20100725145914.GA5776@rivendell
RFC: 3.0 (git), now with bundles
