Re: Newbie grief

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]