Re: git and transition from native to non-native package
- To: firstname.lastname@example.org
- Subject: Re: git and transition from native to non-native package
- From: Eric Cooper <email@example.com>
- Date: Mon, 14 Jul 2008 11:48:31 -0400
- Message-id: <20080714154831.GA28567@localhost>
- Mail-followup-to: firstname.lastname@example.org
- In-reply-to: <20080714094511.GE13557@usha.takhisis.invalid>
- References: <20080709181357.GA12133@localhost> <20080714094511.GE13557@usha.takhisis.invalid>
On Mon, Jul 14, 2008 at 11:45:11AM +0200, Stefano Zacchiroli wrote:
> May I ask you why you want to have 2 separate repositories, one upstream
> and one downstream? I would personally go for a single git repository in
> pkg-ocaml-maint, with an upstream branch with just the code and a debian
> branch with the debian packaging stuff. Given that scenario you can
> easily both make upstream releases of just the code and debian package
> releases with both the code and the packaging stuff.
Yes, as I started learning more about git this occurred to me, too. I
was wondering, though, if it would break any assumptions made by our
current or future git-buildpackage tools. I.e. having the actual
upstream in the same repo, not just a [pristine-]tarball; or having
debian/ stuff in its own branch (using "master" would be misleading, I
Also, does anyone have an opinion on whether should I setup the approx.git
repo under packages/ or projects/?
> > Any suggestions on how to do this, or other feedback? Thanks.
> I suggest to spawn an instance of Stephane and his migration scripts on
> the problem :-)
I wish. I tried a naïve edit of his svn2git.py script (replacing
packages by projects, etc.), but the history of the svn repo layout
made it very confused.
I've managed pretty well so far by starting with "git-svn clone", then
doing some manual conversion of its remote tags/* branches into real
git tags, etc. And I'm learning some git-rebase-fu along the way :-)
Eric Cooper e c c @ c m u . e d u