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