On Sun, May 24, 2009 at 03:57:04PM +0200, Stefano Zacchiroli wrote:
> On Sat, May 23, 2009 at 12:55:57AM +0200, martin f krafft wrote:
> > > Now:
> > > - all patches are saved in debian/patches/ and can be used directly with
> > > quilt.
> > Yes, and you can use TopGit to actually develop features on all
> > those TopGit branches, from which you can create that initial patch
> > series.
> > Now we need to figure out how to get the conflict resolutions you
> > made during your git-am loop back onto the TopGit branches where
> > their features are developed.
> > This is the advantage of TopGit: it's centred around the idea of
> > keeping changes to a feature very close to the feature's branch.
> I think the approach hinted by Mehdi is quite interesting and that it
> deserves a bit more of investigation.
> In particular, what do you think you will loose practically using that
> instead of full-fledged TopGit? That is not that clear to me. Better,
> I know what information will not be stored not using TopGit (e.g. the
> merging history), but practically I don't see any disadvantage
> descending from that. On the contrary, what you gain is quite clear:
> you don't fiddle with the complexity of TopGit and you don't have
> forever lasting branches. Also, your patch history is trivially
> versioned as the content of debian/patches/ in master.
FWIW I'm using a similar scheme except that I don't recreate the
patch-queue branch from quilt but simply rebase it frequently on top of
the tracked debian branch (i.e. master). I'm keeping different
patch-queue branches for each release like:
The script then figures out which branch I'm on and recreates the
patch-queue for that branch. This assumes you have all of the patches
condensed on a single branch.
In case of team maintenance either push the patch-queue branch too or
recreate it from quilt as already described.
vcs-pkg-discuss mailing list