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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html