Re: topgit patches

["Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>]

On Fri, Feb 27, 2009 at 01:37:31PM +0100, martin f krafft wrote:
> also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2009.02.26.1515 +0100]:
> > If you need help, I'm also interested to co-maintain the debian
> > package. Just an offer ...  (I don't know the exact way to become
> > a maintainer, if I need to meet a Debian developer, that's no
> > problem, I know one.)
> 
> The Debian package is pretty trivial to maintain on top of upstream
> (thanks to topgit), and I am using it a bit as a test-case for
> workflow experiments. However, if you are interested in packaging,
> by all means, join me. In that case I'd suggest that you make the
> 0.6-1 Debian package after 0.6 is out, and I give you some hints up
> front and then simply stand by to help out.
Great.

> >  1 move all or most topgit-topic-branches to a private namespace, say
> >    refs/top-heads because the patch branches pollute the output of git
> >    branch.
> 
> But aren't the topic branches essentially also plain Git branches?
Yes, sure, but in my workflow I usually have "patch branches" that
really introduce a change and "topic branches" that don't introduce own
changes but only collect "patch branches" in .topdeps.  For me it would
be enough to let the "topic branches" appear in the output of
git-branch.  Currently I have 144 (non-remote) branches in my linux
repo:

	-   3 branches are exported topgit developments;
	-   1 master branch (don't know off-hand what it contains);
	-   9 topgit topic branches; and
	- 131 topgit patch branches.

Skipping the 131 patch branches would greatly improve usability.

> >  2 export method that works like the existing linearize but creates
> >    branches for topgit branches living in refs/heads and merges these
> >    properly without linearisation.
> >    (obviously depends on 1)
> 
> I am not sure I understand what you are trying to do.
For example I collect arm-linux related patches that are ready for
upstream in a branch called t/armmisc-master, and patches that are not
ready in t/armmisc-pu.  t/armmisc-pu depends on t/armmisc-master.  When
I export t/armmisc-pu (usually to armmisc-pu) I want that a branch
armmisc-master is created that is an ancestor of armmisc-pu that just
contains the patches in t/armmisc-master.

Another scenario is if I'm working on a platform, say imx, I have
several upstreams: arm, i2c, mtd etc.  Here I want to have a topic
branch that contains all my imx patches and provides proper branches to
pull for my upstreams.  So the involved topgit topic branches are named:

	t/imx-master
	t/imx/arm-master
	t/imx/i2c-master
	t/imx/mtd-master

and the exported result has to look like this:

	                 arm-patch1 -- arm-patch2 ... arm-patchK
	               /                                        \
	              /                                          \
	linus/master  -- i2c-patch1 -- i2c-patch2 ... i2c-patchL-- imx-master
	              \                                          /
	               \                                        /
	                 mtc-patch1 -- mtd-patch2 ... mtd-patchM

and arm-patchK, i2c-patchL and mtd-patchM are the heads of the branches
imx/arm-master, imx/i2c-master and imx/mtd-master respectively.

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |