Re: topgit patches

From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Feb 27, 2009, 19:42 UTC
Message-ID: <20090227194252.GB24054@pengutronix.de>
In-Reply-To: <20090227123731.GA22696@piper.oerlikon.madduck.net>

On Fri, Feb 27, 2009 at 01:37:31PM +0100, martin f krafft wrote:

Show 12 quoted lines

> 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.

Show 5 quoted lines

> >  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.

Show 6 quoted lines

> >  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/  |