Re: rethinking patch management with GIT / topgit

[Petr Baudis <pasky-AlSwsSmVLrQ@public.gmane.org>]

On Sat, Mar 20, 2010 at 07:53:34PM +0100, Thomas Koch wrote:
> 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.

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

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