Show 82 quoted lines
> 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