moving iceweasel to git

[Alexander Sack]

On Tue, Oct 09, 2007 at 07:16:53PM +0200, Mike Hommey wrote:
> On Tue, Oct 09, 2007 at 11:05:55AM +0200, Alexander Sack wrote:
> > Hi Eric,
> > 
> > On Sat, Oct 06, 2007 at 06:26:34PM -0400, Eric Dorland wrote:
> > > Hello friends of iceweasel,
> > > 
> > > A couple of months ago I tried to convert the iceweasel SVN repo into
> > > git. It didn't go well. I ran it all weekend and it still hadn't
> > > completed. I think because of a bad cvs2svn originally wasn't the
> > > finest conversion, producing a lot of revisions. And the various svn
> > > mv's due to renames isn't helping. I don't think even if it gets
> > > converted successfully, it won't give a useful result.
> > > 
> > > So instead of just starting from scratch I think I will try to replay
> > > all the phoenix/mozilla-firefox/firefox/iceweasel source packages up
> > > on snapshot.debian.net to produce at least a useful history.
> > > 
> > > Anyone have any better ideas?
> > 
> > we have the upstream branch for browser et al already in the
> > archive.
> 
> Except last time I checked, it was updated by hand from the cvs and
> didn't include releases.

Well, until someone actually uses those branches, I won't put much
efford in it. Further, (daily) auto updating isn't really helpful
either. Usually updating on releases should be enough. This can be
done manually or script supported or whatever ...

> 
> > Would you be willing to rebase against that branch on every
> > new upstream release? e.g. for the sake of keeping our patches on top
> > in a distinct/exportable fashion?
> 
> rebasing is a big problem with shared git repositories. I think we can
> come up with ways to list our patches even if they are applied to a
> regularly merged branch.

How?

Actually I don't really think its a big problem to rebase if you have
a small set of maintainers that know what to do. People outside of
this group probably can just clone whenever they want and don't really
care on whether the branch is regularaly rebased or not.

Anyway, please explain your _merge_ driven approach. Won't you loose
the ability to extract/compare/replace/QA distinct patches? If so, why
don't you care ;)?

 - Alexander