Re: Newbie grief

From: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date: May 4, 2012, 20:00 UTC
Message-ID: <20120504200051.GP14230@opensource.wolfsonmicro.com>
In-Reply-To: <4FA41E8E.20900@palm.com>

On Fri, May 04, 2012 at 11:23:10AM -0700, Rich Pixley wrote:

Show 6 quoted lines

> 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.