Re: Newbie grief

From: Jakub Narebski <jnareb@gmail.com>
Date: May 4, 2012, 19:14 UTC
Message-ID: <m3d36jrc74.fsf@localhost.localdomain>
In-Reply-To: <4FA41E8E.20900@palm.com>

Rich Pixley <rich.pixley@palm.com> writes:

Show 28 quoted lines

> On 5/4/12 08:56 , Mark Brown wrote:
> > On Thu, May 03, 2012 at 01:52:35PM -0700, Rich Pixley wrote:
> >
> > > It's not just hg.  It's other source code control systems as well.
> > > Check out any of the other daggy guys.  So sure, I'll admit a bias
> > > for current technology over older tech.
> >
> > I'm still not sure what's missing here without a central server?   The
> > other DVCSs I've used (which don't include hg) do require that the user
> > trigger a merge operation somehow; they don't magically go and merge
> > things without being asked.
> 
> Nor does hg.  Rather, it allows the collision to be tracked within the
> source code control tool so that anyone who wants to see it can do so,
> and so that anyone who wants to merge it can do so.  The data flow
> paths for collisions and proposed changes can follow precisely the
> same paths as any other code changes.  No meta channel is required.
> 
> 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.
> 
> 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.

Well, perhaps Git doesn't support "central repository" workflow, where
users push to common repository, as well as Mercurial.  The main
workflow is based on pairs of private (non-bare) + public (bare)
repositories, one pair for each developer.  You push to own
repository, and pull from other public repositories.
 
Note that there is no problem in Git in "pull" direction (at least for
pulling single branch): you either fast-forward (be updated), or be
asked to perform a merge.  Instead of anonymous heads you get
automatically named remote-tracking branches.

With respect to "push" direction Git assumes that you don't have shell access to remote repository, so there is nobody to perform a merge; hence assymetry between "git pull" and "git push".

BTW. can you get in Mercurial which anonymous head comes from which repository?

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

Well, if you have that much activity, you better switch workflows away from "central repository" one, perhaps to maintainer + lieutenants pull-based workflow.

Or you can axplicitely push to side branch

  $ git push repo master:foo/master

and ask in side channel to merge it.

For me using multi-tailed (multi-head) branches instead of remote-tracking branches serves to blur important distinction (assymetry) between pull and push directions.

Now if I understand correctly what you wanted to have is a set of remote repositories, updated only by you (or at least updated in such way that fast-forward non-merge updates are more common than merges), and a way to fetch from those repositories so that branches gets updated to most recent version from among the set of those repositories, isn't it?

That's quite advanced workflow / requirement, isn't it?

-- 
Jakub Narebski