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
