On Fri, May 04, 2012 at 11:23:10AM -0700, Rich Pixley wrote: > This is a different situation from either the one where I, > specifically me, must merge or the one where I intend my changes to > stay separated from other development, (a new "branch"). The > situation with multiple heads allows the merge, the branch, even the > decision about whether to merge or branch, to be delayed > indefinitely. So, git does actually allow this quite happily - people can publish and merge whatever they feel like. What seems to be missing (as far as I can tell without having used hg) is the ability to associate random scratch branches from various places with each other and then do things with that information. Like I said in another e-mail elsewhere in the thread this does make sense to me, though it's not a current workflow. > The fact that it allows for this also allows for a number of > different repository network architectures, all of which are blocked > in git because of the push problem. In git, those decisions must be > made _before_ the push. They're only blocked if you don't want to create new branches; idiomatic git is much more free and easy with that idea so a lot of the time what people would say is that is to just create topic branches. > There's also a possibility of nonterminating merges. That is, if my > team is making changes faster than you can merge them, then you'll > never get to push your changes. With dual heads, you still can. > And then anyone who wants to can merge them. Again, this only applies if everyone has to merge onto the same branch and do it regularly - in normal git workflows this doesn't really occur as the final merge branch requires some review/approval process and unmerged work branches are cheap to create and publish.
Attachment:
signature.asc
Description: Digital signature