Subject: Re: rethinking patch management with GIT / topgit
Newsgroups: gmane.comp.version-control.packaging, gmane.comp.version-control.git
Date: 2010-03-21 20:36:26 GMT (1 year, 46 weeks, 2 days, 19 hours and 26 minutes ago)
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