[Pkg-fonts-devel] converting fontforge packaging repo to git

[Vasudev Kamath]

On Mon, Feb 6, 2012 at 11:51 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> right, my point there was to make sure there it was clear that the
> debian branch was for the debian package.  If you prefer that we name it
> "master", i'm OK with that, though i think the name "debian" is more
> obvious :)
Naming it master would be great :)

>> As master
>> in git repo for a package contains upstream with debian directory.
>
> I'm not sure i understand what you mean by this last sentence.  can you
> explain?

Have a look at this repository of mine [1] as you can see master is
nothing but upstream branch with debian tag. This will be created by
git-import-dsc command from git-buildpackage. I feel having repo in
this format will be more convinient if we want to use git-buildpackage
on the repo.

> As a counterexample, the upstream git repo has a branch named master
> that does not contain the debian repository.

That should not be a problem I think we can make our upstream branch
to track the master branch of upstream git repository.

>> And
>> debian folder changes are tracked using tags something like
>> *debian/version-1*
>
> i've created tags named fontforge_debian/0.0.20110222-6
>
> is this naming scheme a problem?  I prefer to not use the generic tag
> names like "debian/vX.X-X" because of the ambiguity it creates in the
> abstract global git repo [0], though i'm capable of being persuaded
> otherwise by reasonable argument.
>
> I'm happy to write up a debian/gbp.conf that formalizes the tagging
> scheme so that our tools can agree on the same thing.

This should not be a problem debian/version-1 is what git-buildpackage
uses by default but we can tell gbp which should be the debian tag
using gbp.conf inside debian/ folder

>> After that I think we may need
>> pristine-tar branch if we plan to make repo git-buildpackage
>> friendly.
>
> well, any future pristine-tar branch is going to be populated with fake
> data if we're making builds from upstream's git :/  But i agree with you
> that if we plan to make this work, it would be nice to make it work with
> git-buildpackage.  Is there no way to get git-buildpackage to
> acknowledge an upstream tarball that's just generated via git-archive
> without having a pristine-tar branch?  or will we need to have an empty
> pristine-tar branch or something?

If we have orig.tar generated from upstream git then may be we can
tell git-builldpackage not to checkout pristine-tar or one more way I
can think is pull upstream changes generate a tar ball and use
pristine-tar utility to commit the generated tarball to pristine-tar
branch. I think second option looks more easy right?

>
> I think i still want to review and clean up the imported git-svn history
> in order to remove its back-and-forth inclusion of the upstream sources.
>  I suspect that filtering those changesets out of the debian branch's
> history will save us 10 or 20 MiB for the repo as a whole.  (unless
> Christian thinks losing those changesets would be a historical mistake).
>
> After thinking about it for a couple days, i also think that my attempt
> to merge the git-svn history with the upstream history at more than one
> historical point was probably a bad idea (and i also implemented it
> poorly).  So i think the right thing would be to take one more stab at a
> filtered git-svn, merge it with upstream's repo just at the 20110222
> release, and then work from there on a new snapshotted release.
>
> Does this seem reasonable?  If so, i'll take a stab at it over the next
> few days, and publish a repo someplace useful.

I really don't have clue on this. I think Christian can answer this question :)


[1] http://anonscm.debian.org/gitweb/?p=debian-in/fonts-pagul.git;a=summary
-- 

Vasudev Kamath