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/~madduck http://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
