Re: Patch mgmt workflow proposal
also sprach Ben Finney bignose+hates-s...@benfinney.id.au [2011.08.02.0223 +0200]: This comes about ¾ of the way to the history pollution done by TopGit. I consider it very useful information, when needed. It's only pollution if you let it be so. That is a very wise statement, and I agree. Not only would users potentially get confused by this additional branch (which is an implementation detail), it would also get in the way in gitk output (cf. pristine-tar) and annoy even the unconfused. That's an argument not for hobbling a useful branching-and-merging workflow, but for improving the output of those programs. Advocate with Git (and other VCSen) to hide merged revisions by default, the way Bazaar does. One person's reasonable default is another person's nightmare. Fact is that we have new contributors who are being shyed away by complexity. Fact is also that you can already hide information explicitly. I have already dipped my foot in the water on this [http://bugs.debian.org/636228], but I feel somewhat it's an uphill battle. In the end, the best solution is one that doesn't expose implementation details in the first place. The discussion at http://www.spinics.net/lists/git/msg162549.html is shaping up to be interesting. -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems http://lavender.cime.net/~ricky/badgers.txt digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ 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
also sprach Ben Finney bignose+hates-s...@benfinney.id.au [2011.08.02.0229 +0200]: 1. you develop your features on branches, but you do not push the branch heads; Right. The feature branches stay only with the people who are interested; usually the people actually working on each one. You do need to ensure that everyone has the objects they reference, as these objects are used to generate the patches. 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. With Bazaar, the branches have their own distinct existence, and can be re-created at will by anyone who has the identifier. Is that the same for Git? Yes. Git's branches are just human-readable aliases for SHA-1's, with the added functionality that a commit advances them to the child. 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). I don't see that brittleness; maybe that's because of the way Bazaar keeps track of merges explicitly. I don't think it has anything to do with merges. The brittleness comes from the fact that we are storing a text-representation of an implementation detail in a content blob in the repository. This is redundant information in a place that users might well touch with their text editors, and this means that the redundant information could go out-of-sync. 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. That's a big plus, in my view; but then again Bazaar has the sensible default of hiding merged revision data until it's requested by the user. Why is it a plus? If you already applied all changes, why bother exporting the patches? Thanks for your time, -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems if ever somethin' don't feel right to you, remember what pancho said to the cisco kid... `let's win, before we are dancing at the end of a rope, without music.' -- sailor digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ 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
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
also sprach Thomas Koch tho...@koch.ro [2011.08.02.1732 +0200]: 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. This is exactly what TopGit does: a top-base is the merge of a branch's dependencies. -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems if a man treats life artistically, his brain is his heart. -- oscar wilde digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ 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
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, -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems may the bluebird of happiness twiddle your bits. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ 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
