Re: [Pkg-fonts-devel] converting fontforge packaging repo to git
On Mon, Feb 6, 2012 at 11:51 AM, Daniel Kahn Gillmor
> 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
Have a look at this repository of mine  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.
>> debian folder changes are tracked using tags something like
> 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 , 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
> 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 :)