Re: Newbie grief

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.