Re: rethinking patch management with GIT / topgit
Petr Baudis: > > - it pollutes the patch branches with metadata (.topmsg, .topdeps) > > I'd like to single this out - this is a very arbitrary decision and has > its distinct pros and cons compared to alternative approaches, and was > not taken lightly. It wouldn't be that difficult to go in a different > way and it's not a fundamental limitation. It's also the most minor problem I see, rather a matter of taste. > > - AFAIK nobody has solved the problem of managing different patchsets > > with tg > > Why not just manage them in separate repositories? If you want to pick > patches between patchsets, that should be easily posible through remotes. You mean having multiple local working directories per project? That's not nice. If you also work on the project with an IDE, it'd most probably mean setting up the same project multiple times. > I agree that topgit really sucks in many areas. :) While it is usable > in practice if you know what you are doing, in some aspects it never got > out of the proof-of-concept stage. Thank you for not taking it personaly! :-) > > 1) merge commits to save history > > > > git allows the free creation of merge commits with an arbitrary content > > tree. So we can create an octupus merge combining all patch-branches > > while the content of this merge can contain meta data about a patchset > > instead of the content of the merged commits. > > Such a merge commit thus provides a pointer to all the history of all > > patches and can contain all metadata about the merged patch branches. > > Pushing only a branch or tag with this commit to a central repository > > thus pushes all the history of all contained patches. > > But how is this different from TopGit's approach? TopGit doesn't use > octopus merges for various reasons (I mainly guess since I was too lazy > to implement that), but that's more of an implementation detail than > anything conceptual. Maybe I didn't make clear that the commits on the patchset branch should not necessarily contain the merged content of all patches. The role of the merges is solely to keep pointers to the commits making up the patch branches. Now that you're asking there may however be a similarity to topgit in that you can have one topgit controlled branch that combines all topgit branches belonging to the same patchset. However there still remain some differences: - in tg you need to push all tg branches while in my approach you'd need to push only one branch per patchset - As far as I understand tg, all commands are repository global while for the Debian packaging use case you'd need patchset local commands: - tg export export as a quilt series - tg summary gives summary information for the branches of - tg delete removes from . However old history of is still recorded in the history of the -branch - tg add adds to (The question is open, where to record the merge resolution of all patches) - tg recreate Creates a new patchset with root by creating new patch branches for each patch branch in This command is useful if you need to keep the old patchset to maintain an older version of your Debian package. > > 2) collapse / expand branches > > > > Managing a Debian package in stable, unstable and experimental can > > quickly doom you to manage at least three different patchsets with > > possibly three different roots. The list of branches grows in the > > douzens. Which branches belong to which patchset? Which branches are > > already pushed or pulled? It may be an advantage to see only some main > > branches and the branches of one patchset I'm currently working on. > > The tool I propose would manage each patchset in one branch per patchset. > > This branch has two roles: > > - keep the metadata of the patchset as files in the content tree > > - keep pointers to the top of the patch-branches in the parent pointers > > of the commit > > With the help of such a patchset-metadata-branch I can: > > - delete the patch-branches of one patchset while the commits are kept > > save - recreate the patch-branches of one patchset > > The disadvantage is that you will have to invent a lot of arbitrary > metadata and wide range of commands to manipulate and work with this > metadata, all to accomplish something that _is actually one of the main > Git functions to do_! 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. > 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 a
Re: rethinking patch management with GIT / topgit
Hi! On Sat, Mar 20, 2010 at 06:02:51PM +0100, Thomas Koch wrote: > I'd like to argue, that topgit (tg) fails to fullfill it's task and propose a > different approach to the problem of patch management on top of git. > > IMHO tg fails due to the following reasons: > > - it pollutes the patch branches with metadata (.topmsg, .topdeps) I'd like to single this out - this is a very arbitrary decision and has its distinct pros and cons compared to alternative approaches, and was not taken lightly. It wouldn't be that difficult to go in a different way and it's not a fundamental limitation. > - AFAIK nobody has solved the problem of managing different patchsets with tg Why not just manage them in separate repositories? If you want to pick patches between patchsets, that should be easily posible through remotes. > - it's to complicate > - even after 1 1/2 years topgit isn't feature complete and development seems > to stagnate > - there also aren't best practices documented > - it quickly fills the list of branches > - it's very easy to break something > > Although the above is quite a harsh judgement, I'd like to note, that tg has > had its merrit to promote one right idea: Patches should be managed in the > form of branches by the means of the underlying VCS and not as simple > patchfiles. I agree that topgit really sucks in many areas. :) While it is usable in practice if you know what you are doing, in some aspects it never got out of the proof-of-concept stage. > The new approach I'd like to propose is based on two core ideas: > > 1) merge commits to save history > > git allows the free creation of merge commits with an arbitrary content tree. > So we can create an octupus merge combining all patch-branches while the > content of this merge can contain meta data about a patchset instead of the > content of the merged commits. > Such a merge commit thus provides a pointer to all the history of all patches > and can contain all metadata about the merged patch branches. Pushing only a > branch or tag with this commit to a central repository thus pushes all the > history of all contained patches. But how is this different from TopGit's approach? TopGit doesn't use octopus merges for various reasons (I mainly guess since I was too lazy to implement that), but that's more of an implementation detail than anything conceptual. > 2) collapse / expand branches > > Managing a Debian package in stable, unstable and experimental can quickly > doom you to manage at least three different patchsets with possibly three > different roots. The list of branches grows in the douzens. Which branches > belong to which patchset? Which branches are already pushed or pulled? > It may be an advantage to see only some main branches and the branches of one > patchset I'm currently working on. > The tool I propose would manage each patchset in one branch per patchset. > This > branch has two roles: > - keep the metadata of the patchset as files in the content tree > - keep pointers to the top of the patch-branches in the parent pointers of > the > commit > With the help of such a patchset-metadata-branch I can: > - delete the patch-branches of one patchset while the commits are kept save > - recreate the patch-branches of one patchset The disadvantage is that you will have to invent a lot of arbitrary metadata and wide range of commands to manipulate and work with this metadata, all to accomplish something that _is actually one of the main Git functions to do_! 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. > For Debian packaging one last function is needed: export a patchset as quilt > series. > > Is my explanation understandable? Could this approach work or did I miss > something? Who has time to implement it (GSOC?)? It's especially not clear at all whether you propose to start over or just make two improvements to TopGit, and if the former, how would your approach differ from TopGit in all the other aspects. It's all a bit ambiguous. -- Petr "Pasky" Baudis http://pasky.or.cz/ | "Ars longa, vita brevis." -- Hippocrates ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
rethinking patch management with GIT / topgit
Hi, I'd like to argue, that topgit (tg) fails to fullfill it's task and propose a different approach to the problem of patch management on top of git. IMHO tg fails due to the following reasons: - it's to complicate - AFAIK nobody has solved the problem of managing different patchsets with tg - it pollutes the patch branches with metadata (.topmsg, .topdeps) - even after 1 1/2 years topgit isn't feature complete and development seems to stagnate - there also aren't best practices documented - it quickly fills the list of branches - it's very easy to break something Although the above is quite a harsh judgement, I'd like to note, that tg has had its merrit to promote one right idea: Patches should be managed in the form of branches by the means of the underlying VCS and not as simple patchfiles. The new approach I'd like to propose is based on two core ideas: 1) merge commits to save history git allows the free creation of merge commits with an arbitrary content tree. So we can create an octupus merge combining all patch-branches while the content of this merge can contain meta data about a patchset instead of the content of the merged commits. Such a merge commit thus provides a pointer to all the history of all patches and can contain all metadata about the merged patch branches. Pushing only a branch or tag with this commit to a central repository thus pushes all the history of all contained patches. 2) collapse / expand branches Managing a Debian package in stable, unstable and experimental can quickly doom you to manage at least three different patchsets with possibly three different roots. The list of branches grows in the douzens. Which branches belong to which patchset? Which branches are already pushed or pulled? It may be an advantage to see only some main branches and the branches of one patchset I'm currently working on. The tool I propose would manage each patchset in one branch per patchset. This branch has two roles: - keep the metadata of the patchset as files in the content tree - keep pointers to the top of the patch-branches in the parent pointers of the commit With the help of such a patchset-metadata-branch I can: - delete the patch-branches of one patchset while the commits are kept save - recreate the patch-branches of one patchset For Debian packaging one last function is needed: export a patchset as quilt series. Is my explanation understandable? Could this approach work or did I miss something? Who has time to implement it (GSOC?)? Best regards, Thomas Koch, http://www.koch.ro ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
cursuri online
Title: cursuri online EVRIKA : solutia optima de perfectionare profesionala. Cursuri online de inspector resurse umane ,formator, comunicare, etc -test dupa fiecare lectie -forum moderat de lectorul cursului -acces timp de 6 luni la suportul de curs si forum = beneficiati de toate noutatile din aceasta perioada -test final in mai multe variante. - diploma eliberata de central nostru de pregatire Toate acestea doar pentru 50 ron www.cursonline.eu___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
