From: Rich Pixley <rich.pixley@palm.com>
Date: Thu, 03 May 2012 19:13:46 GMT
Subject: Re: Newbie grief
Message-ID: <4FA2D8EA.7030809@palm.com>
In-Reply-To: <08704bd2e32343a4b9def80e4fa1efa2-mfwitten@gmail.com>

On 4/30/12 22:32 , Michael Witten wrote:
> On Mon, 30 Apr 2012 20:04:25 -0700, Rich Pixley wrote:
>
>> I don't need separate branches for each repository.  What I really want
>> is a common branch whose changes I can push back and forth between the
>> various repositories, or coordinate through a central cache, without
>> worrying about the underlying details that git is forcing me to confront.
>
> Here's a start for a more precise discussion.
>
> Sincerely,
> Michael Witten
>
>
> Cache server:
>
>    $ git clone --mirror "$uri_for_central_repo"
>
> Machine A:
>
>    $ git clone "$uri_for_cache_repo"
>    $ git checkout -b feature_0 origin/feature_0
>    $ # ... do some work ...
>    $ git push --set-upstream origin HEAD:shared/feature_0
>    $ git config push.default upstream
>
> Machine B:
>
>    $ git clone "$uri_for_cache_repo"
>    $ git checkout -b feature_0 origin/feature_0
>    $ # ... do some work that conflicts with work done on Machine A...
>    $ git push --set-upstream origin HEAD:shared/feature_0
>    To $uri_for_cache_repo
>     ! [rejected]        HEAD ->  shared/feature_0 (non-fast-forward)
>     error: failed to push some refs to '$uri_for_cache_repo'
>    To prevent you from losing history, non-fast-forward updates were rejected
>    Merge the remote changes (e.g. 'git pull') before pushing again.  See the
>    'Note about fast-forwards' section of 'git push --help' for details.
>    $ git pull origin shared/feature_0
>    From $uri_for_cache_repo
>     * branch            shared/feature_0 ->  FETCH_HEAD
>    Auto-merging a
>    CONFLICT (add/add): Merge conflict in a
>    Recorded preimage for 'a'
>    Automatic merge failed; fix conflicts and then commit the result.
>    $ # ... resolve conflict and commit results ...
>    $ git push --set-upstream origin HEAD:shared/feature_0
>    $ git config push.default upstream
>
> Machine A:
>
>    $ git pull # pulls in origin's shared/feature_0
>    $ # ... do some work ...
>    $ git push # pushes to origin's shared/feature_0
>
> Machine B:
>
>    $ git pull # pulls in origin's shared/feature_0
>    $ # ... do some work ...
>    $ git push # pushes to origin's shared/feature_0
>
> Machine A:
>
>    $ git pull
>    $ git remote add central "$uri_for_central_repo"
>    $ git push central HEAD:feature_0 # Assume there is a conflict
>    To $uri_for_central_repo
>     ! [rejected]        HEAD ->  feature_0 (non-fast-forward)
>    error: failed to push some refs to '$uri_for_central_repo'
>    To prevent you from losing history, non-fast-forward updates were rejected
>    Merge the remote changes (e.g. 'git pull') before pushing again.  See the
>    'Note about fast-forwards' section of 'git push --help' for details.
>    $ git pull central feature_0
>    $ # ... resolve conflict and commit results ...
>    $ git push central HEAD:feature_0 # Assume it succeeds this time
>    $ # Let's update the cache repo from Machine A:
>    $ git fetch central
>    $ git push origin 'refs/remotes/central/*:refs/heads/*'
>
> Machine B:
>
>    $ git pull
>    $ git pull . origin/feature_0 # Get new stuff cached from central server

This is probably what I'm going to end up using.

Just for comparison, here's a similar process in hg.

Cache server:

   $ hg clone $uri_for_central_repo

Machine A:

   $ hg clone $uri_for_cache_repo
   $ # ...do some work...
   $ hg push

Machine B:

   $ hg clone $uri_for_cache_repo
   $ # ...do some work...
   $ hg push # assume this collides
   pushing to $uri_for_cache_repo
   searching for changes
   abort: push creates new remote head 6d2eb0a6a278!
   (you should pull and merge or use push -f to force)
   $ hg push -f # the pull and merge case parallels git, so let's use 
push -f.

Any repo:

   $ hg pull # pulls in all changes including the dual heads
   $ hg merge # collapses the dual heads
   $ hg commit # commits the merge
   $ hg push

Machine A:

   $ hg pull # pulls in all changes so far
   $ hg up
   $ #... do some work ...
   $ hg push

Machine B

   $ hg pull
   $ hg up
   $ # ... do some work ...
   $ hg push

Any repo:

   $ hg pull $uri_to_central_repo
   $ hg merge
   $ hg push $uri_to_central_repo
   $ hg push # default is cache repo

Machine B:

   $ hg pull


Some Conclusions:

* the work flows are similar.

* the hg commands are simpler and have the defaults that we want, 
primarily because no extra branches are required.

* the hg error messages are straightforward, clear, and don't require 
any deep knowledge of the source code control system or it's 
limitations.  (I still don't understand what the git message on 
collision is saying.)

* hg has more options about how to handle the collisions or the merges. 
  While git can mimic some of those options, doing so requires a priori 
knowledge that isn't stored in the source code control system and 
therefor requires a human exchange which is optional with hg.

--rich