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

[Daniel Kahn Gillmor]

On 02/04/2012 12:23 PM, Vasudev Kamath wrote:
> 
> remotes/origin/debian
> remotes/origin/upstream
> 
> So I did these to get them on my local machine.
> 
> git branch --track debian remotes/origin/debian
> git branch --track upstream remotes/origin/upstream

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 :)

> 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?

As a counterexample, the upstream git repo has a branch named master
that does not contain the debian 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.

> 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?

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 do notice that there seems to be a git repository already on
git.debian.org [1], created by Rogerio Brito back at the end of 2010.
It doesn't seem to share any commits with upstream's git repo, however,
or with the conversion i've been working on.

Rogerio, can you explain what is going on with that repo?  It seems like
we should be better-sync'ed to upstream's repository, if possible.
Would you mind if we removed that repository and replaced it with one
converted the way Vasudev and Christian and i have been proposing?

Is anyone currently using the fontforge repo at git.debian.org ?

	--dkg

[0] http://www.debian-administration.org/users/dkg/weblog/81
[1] git://git.debian.org/pkg-fonts/fontforge