Better name for dpush wanted

[Stephen J. Turnbull]

Martin Pool writes:
 > 2009/5/2 Stephen J. Turnbull <stephen at xemacs.org>:
 > > Andrew Bennetts writes:
 > >
 > > > I should point out that "pull" seems like a good name to me
 > > > because it's  very much like "push" but in the opposite
 > > > direction.  The options that they both take and the effects of
 > > > those options are basically the same, except that pull cannot
 > > > create a new branch whereas push can.
 > >
 > > I see your point.  So the identification of content that git
 > > accomplishes by simply declaring that the same content is the same
 > > object (and optimizes by using content digests as names for copies of
 > > objects), in Bazaar is accomplished by restricting the behavior of
 > > push and pull to exact synchronization.
 > 
 > I think you must be misunderstanding something if you think
 > Andrew's message implies any fundamental difference in what's
 > representable in git and bzr.

I don't.  It's how it's represented, and the implications for UI that
I'm interested in.

 > (or maybe I'm misunderstanding you)

Maybe.  What I have in mind is that in git, there is no
"synchronizing" to be done for content.  You either have something or
you don't.  If you want to work with my branch, you make a copy of it
locally, but it is not a different branch from mine.  All that needs
to be kept synchronized are the tags, whether fixed tags or branch
tags.  Fixed tags should not change their references, so the fixed
tags have the same names across repositories.  If there's a collision
or divergence, you and I probably need to talk.  But branch tags are
intended to be updated automatically, so "my somebranch" must be kept
distinct from "your somebranch", otherwise the same name will come to
refer to different histories.  In the early days of git this kind of
confounded divergence caused everybody a lot of pain, because that
tracking wasn't done automatically.

In recent git this is automatically done via the use of "remotes",
each of which is basically a namespace-mapping pair, the namespace
being the set of branch tags in the remote repository, and the mapping
being from the remote namespace to the local namespace.  This mapping
is *not* an identity, however; it is the default merge target.

What this means is that git users don't need to think in terms of
synchronizing the local branch to the remote branch.  You have an
identical copy, which you can access by name relative to the remote:
remote/tag.  Thus, sharing branch tag names doesn't mean being the
"same" branch, it means being related, and indicates an intention to
synchronize by merger.  A git pull necessarily implies updating a
local identical copy of the remote branch (called "git fetch"), and
then transfering the relevant pieces into the local branch (which is
conceptually a merge, not a synchronization, and is so implemented).

But in Bazaar, leaving aside pending work on colocated branches and
looms, can't represent that in a single branch.  So you need to make a
separate branch for synchronization, or deal with remote operations.
Both are painful... ask Nick Allen who has been asking for a
git-remote-like revision cache for months.

Thus bzr needs explicit mirroring commands, where git doesn't (very
much; the case of pushing to a public repository is a special case).

 > Push A->B means: if tip_B is an ancestor of tip_A, set tip_B to tip_A,
 > and if B is local update its working tree to that new revision.
 > Pull A->B means: if tip_B is an ancestor of tip_A, set tip_B to tip_A,
 > and if B is local update its working tree to that new revision.
 > 
 > I'm pretty sure git does very similar operations when transferring
 > branch pointers between repositories.

Indeed it does.

 > Monotone does an interesting variation on this iirc which is that if
 > they're diverged, it puts the branch in a state of having two (or
 > more) heads, so that you can then later merge them.

Mercurial does exactly the same thing.  In fact, bzr does, too, but
doesn't provide easy ways to refer to them IIUC.

 > > But since push and pull cannot be the only modes of
 > > communication, I suspect that this failure to identify content
 > > with "objecthood" costs Bazaar a lot of theoretically unnecessary
 > > interbranch communication.
 > 
 > At least one of us is confused in this bit.

I'm mostly referring to Nick Allen's kind of caching, which git does
automatically, but also provides useful handles for the revisions that
are cached.  Also copies from pristine mirrors to working copies.