Re: rethinking patch management with GIT / topgit

From: Petr Baudis <pasky-alswssmvlrq@public.gmane.org>
Date: Mar 21, 2010, 20:36 UTC
Message-ID: <20100321203626.GE3533@machine.or.cz>
In-Reply-To: <201003201953.34666.thomas-5j3myg3OO4w@public.gmane.org>

On Sat, Mar 20, 2010 at 07:53:34PM +0100, Thomas Koch wrote:

Show 6 quoted lines

> Petr Baudis:
>   - tg recreate <patchset> <newbase> <new patchset name>
>     Creates a new patchset with root <newbase> by creating new patch branches 
> for each patch branch in <patchset>
>     This command is useful if you need to keep the old patchset to maintain an 
> older version of your Debian package.

This means wiping out history again; in TopGit, you would ideally checkpoint all the branches within the patchset, then just tg update your branches. It's another matter that the former is now difficult to do easily.

Show 8 quoted lines

> I don't see this. What do I miss? All metadata I'd need to manage is:
> - one file with the name of each branch, it's last commit and the names of its 
> dependencies (the root of the patchset, if empty)
> - one message file for each patch
> - the root of the patchset
> 
> The example commands given above would manipulate or read the patchset branch 
> in the background much like pristine-tar does it with its metadata branch.

Hmm, to a degree I misunderstood your idea. You would still need quirky commands to update the references when you make a new commit, to go to a certain patch (at which point git will start acting a bit annoyed since it's not on a branch), etc. Other than that, I can offer only my gut feeling. ;-)

Show 8 quoted lines

> >   Wouldn't it be better to do the collapsing/expanding instead, e.g.
> > have a convention for patchset/stage branch tying up all patchset/*
> > branches, and an alias that lists only */stage branches and another that
> > lists only patchset/* minus patchset/stage branches.
> So you propose not to delete/recreate the patch branches but to provide extra 
> commands to list only the desired subset of branches? This would still mean 
> that I'd see douzens of patch branches in gitweb and that I't need to push 
> douzens of branches to my co-packagers. - That doesn't solve it for me.

There are already some patches in the wild to make gitweb topgit-aware; I don't see why is the latter a problem.

> I hope I managed to make it clearer this time. I believe my proposals are 
> incompatible to topgit and thus would require a new project from scratch.

Yes, I finally understood what do you mean, sorry for being a bit dense.

-- 
				Petr "Pasky" Baudis
http://pasky.or.cz/ | "Ars longa, vita brevis." -- Hippocrates