Re: Patch mgmt workflow proposal
Thomas Koch: I had some time on my way back to think about patch bases. Is it right, that it isn't actually necessary to save the commit sha-1s of patch bases? It is my understanding that you could calculate them: 1. $CANDIDATE=$(git merge-base --octopus $DEPENDENCY_NAMES) 2. for each $PATCH_BRANCH_HEAD if NOT $PATCH_BRANCH_HEAD in_history_of $CANDIDATE echo WARNING! $PATCH_BRANCH_HEAD has unmerged commits! I'll leave on a two weeks bycycle tour on wednesday and have a lot of time to think how the above could go wrong. Sorry, the above algorithm is completly wrong, written in a hurry. The idea however was to merge all dependencies in a commit and to merge this commit in the patch branch. The one can search for the oldest commit in the patch branch's history containing all dependencies. Regards, Thomas Koch, http://www.koch.ro ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: Patch mgmt workflow proposal
CC: debian-devel. Please subscribe to vcs-pkg-discuss@lists.alioth.debian.org to follow this topic! martin f krafft: also sprach Thomas Koch tho...@koch.ro [2011.07.30.1229 +0200]: Martin F. Krafft (madduck) was so kind to remind me posting this here. We're right now at debconf discussing different patch mgmt workflows. Thanks to contributions from Joachim Breitner and Guido Günther I've written down an appealing (IMHO) patch mgmt workflow: http://wiki.debian.org/ThomasKoch/GitPackagingWorkflow Here's a summary of what Thomas told me about this: 1. you develop your features on branches, but you do not push the branch heads; 2. the feature branches get merged into an integration/build branch, which is pushed. This way, all contributors get the commits; 3. as part of the build process, the feature branches are exported to a debian/patches series, and each patch file includes additional information, such as dependency data, and also the SHA-1 of the feature branch head at the time when the patch was made; 4. at a later stage, when someone wants to edit a patch, they can create a branch off the SHA-1, merge the branch into the build branch and provide the updated patch (with updated SHA-1), or just provide an updated patch file and let the maintainer update the branch with an interdiff. I see an advantage in this approach because it focuses on debian/patches/* rather than using a potentially-confusing set of branch heads. However, it employs a possibly brittle way to keep track of branch heads (SHA-1's in text files). The thing I do not like about it is that the build branch has all features merged (hence applied to the worktree), *in addition* to tracking the generated patch files in debian/patches/* in the repository. Finally, I would like to highlight that this is very much like the TopGit workflow used in mdadm, with the exception that features are not merged into the build branch, but instead the branch heads are kept around. It is my hope that I can simplify TopGit a bit to make this an equally viable approach, which would be more natural and closer to normal Git usage, at least to me. Cheers, Hallo Martin, seems you've also arrived well at home? Thank you for your additional explanations, I'll work them in my wiki page. I hope I can also address your concerns. It was my initial thought to work on build branches and merge the patch branches in, since this would reflect my latest personal workflow. This is however totally optional. The only thing needed is to get a hold on the commits to save them from garbage collection and a possibility to push them. So as a variation of the described workflow you can establish a special branch that holds references to all feature branch commits in its history. The content of this branch does not matter. A status command should warn you if the head of any feature branch is not in the history this special branch. Another command could create a new commit in this special branch with the parent pointing to all new heads. The concern about brittleness depends a bit on personal judgement. The greatest risk I see is that commit objects could be lost. The tools for this workflow should detect dangling commits in patch branches and print big warnings. The canonical information is stored in debian/patches/*. Inconsistencies between the patch branches and debian/patches/* can also be detected automatically. I had some time on my way back to think about patch bases. Is it right, that it isn't actually necessary to save the commit sha-1s of patch bases? It is my understanding that you could calculate them: 1. $CANDIDATE=$(git merge-base --octopus $DEPENDENCY_NAMES) 2. for each $PATCH_BRANCH_HEAD if NOT $PATCH_BRANCH_HEAD in_history_of $CANDIDATE echo WARNING! $PATCH_BRANCH_HEAD has unmerged commits! I'll leave on a two weeks bycycle tour on wednesday and have a lot of time to think how the above could go wrong. 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/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: rethinking patch management with GIT / topgit
Petr Baudis: On Mon, Mar 22, 2010 at 08:59:40AM +0100, Thomas Koch wrote: In all three cases you're free to either keep or throw away the old patchset. Yes, but to the same degree e.g. with StGIT I'm free to keep the head of the old patch series. That does not mean the operation *preserves* the history, only that the history is still around somewhere in the repository, however it won't be around in other incarnations of the repository and it will not be connected in any way to the current version of the patchset. Yes, if you are lucky you can figure out the name of the previous version, but it's like starting development of each new kernel version by a clean import of the sources. Hi Petr, let me copy the list of methods from my last mail: 1) checkout new patch branches from the top of the old patch branches and merge upstream into each of them 2) recreate (like rebase) the full history of the patch branches on top of the new upstream 3) collapse the branch history and create one commit per patch branch on top of the new upstream From these methods, 3) loses all history, 2) loses some history but preserves the individual history of one patch branch on a new base and 1) preserves all history. Let me give an example for method 1). You've got a patchset identified by the prefix debian/. Now you want to package a new upstream but need to retain the old patchset in case of security updates in Debian stable. Debian stable has version 0.1, new upstream is 0.2. So you - rename the old patchset from debian/ to debian-0.1/ - clone/copy/recreate (pick a name) a new patchset debian/ on top of upstream/0.2. This is done by merging upstream/0.2 into each debian/* branch. - Once you don't maintain version 0.1 anymore, you can delete the debian-0.1/* branches After these steps, the debian/ branch still contains pointers to all commits from the debian-0.1/* branches. It's an additional question, how to deal with commits that are done in debian-0.1/* after the new upstream merge. 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
(top)GIT @ Google Summer of Code
Hi, Google Summer of Code is comming again. The GIT people collect ideas at http://git.wiki.kernel.org/index.php/SoC2010Ideas I already added a paragraph for topgit on the discussion page of the above page, but I don't have a concrete issue for topgit. I only think, that there's still much to be done. :-) 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
talk: (cross distro) packaging with (top)git
(FOSDEM, DEVROOM, CROSSDISTRO) Hi, I'd like to give a talk about packaging with topgit, propose and discuss a workflow and give pointers on where work could be done once for multiple distros. Topgit is a solution on top of git, that helps to manage patches and their dependencies. I'd happily accept anybody else steping in to present the topic. 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
elegant(?) debian topgit workflow?
CC (FYI) to git and debian-devel. see http://vcs-pkg.org Hi, would you be so kind to review my workflow proposal? branches upstream debian/*, fixes/*, features/* - topgit branches based on upstream patches - the hero master - contains the debian/ dir and is the branch we build from All topgit branches are integrated in the patches branch, which is afterwards merged into master. The magic is, that the integration is not a regular merge, but a handcrafted merge and commit with quilt and git plumbing. workflow Every merge starts with reseting patches to the state of upstream: # git checkout upstream (for the first time: git checkout -b patches, otherwise:) # git symbolic-ref HEAD refs/heads/patches Now we're on branch patches with the working tree and index in the pristine state of upstream. We can now integrate the topgit branches: # tg export --quilt debian/patches \ -b debian/use-debian-java-libraries,debian/disable-tests-that-break-on-buildd # quilt push -a # git add debian/ # rm -rf .pc # git add -u Now let's create the commit and specify, which topgit branches were manually merged: # TREE=$(git write-tree) # COMMIT=$(git commit-tree $TREE \ -p debian/use-debian-java-libraries \ -p debian/disable-tests-that-break-on-buildd) # git update-ref refs/heads/patches $COMMIT Now I can happily merge patches into master. advantages -- - The commits of all ever merged topgit branches are preserved, even after tg delete - easy to understand, non cluttered history - Easy to retire topgit branches - Easy to work on old package versions(?): just make a branch from master at desired version, eventually also branch patches branch to work on old patches - The quilt patches are used and therefore tested in the same way, as dpkg- source uses them in version 3 - Integrates with git-buildpackage - Doesn't need anything, that topgit hasn't ATM Todo discuss, test, script 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
packaging solr with topgit
Hi, I've subscribed to this list to get your comments on how it would be best- practice to package solr. Jan-Pascal is so kind to switch the packaging of solr from SVN to GIT to allow better cooperation. So the workflow I think of, inspired by Martin Krafft: - upstream is SVN - use git-buildpackage - get all tarballs in with pristine-tar - unpack each tarball in branch upstream and commit - do the debianization in branch master - create top-git branches upstream/* for patches submitted upstream - create top-git branches master/* for debianization patches - export patches to branch build, based on master Remaining questins: - Is the above workflow good? - Wasn't there also a debian branch for some purpose? - I've read, that it would be possible somehow to reexport old patches with topgit? How? - How can I work on an older release of solr with this setup? 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
