Better name for dpush wanted

[Martin Pool]

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 (or maybe I'm
misunderstanding you) if you think Andrew's message implies any
fundamental difference in what's representable in git and bzr.

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.

The "if B is local" is not essential, it's just because of a technical
restriction that we don't support accessing working trees over eg sftp
transports.  (The tradeoffs in that are a separate debate; it would in
principle be nice to support it.)  At any rate you can just go to the
other machine and run 'bzr update' afterwards.

You can override the ancestry check with --overwrite.  It has some
cost and if the user model was such that when pushing we generally
knew the destination was a slave or mirror of the source, we could
avoid it.

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.

> I guess that this argument puts me in the "dpush should be a separate
> command but needs a better name" camp, since it's not possible to do
> an exact sync across VCSs.
>
> It makes me like Bazaar's model a lot less than I did a few minutes
> ago, though, because it implies that Bazaar itself really does think
> of the content on the local disk as "the branch".  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.

> Isn't the inability of pull to create branches is an implementation
> detail?  I see no reason why a pull couldn't create a new branch, a
> new stacked branch, or even an unnamed colocated head (a la Mercurial)
> waiting to be merged, in the same way that push does.

Yes, it's an implementation detail.

> Actually I find it sort of unnatural that push can create branches; I
> would think it more natural to give this capability to the branch
> command.  Alteratively, nuke the branch command in favor of pull and
> push.  You could even nuke the init command, and create de novo
> branches by pulling or pushing from a special null branch.  (Yeah, I
> know: "Steve, you're weird.  No sane person would think of branch
> initialization as pulling from a null branch!")

Yes, this part makes sense.  I think the way they behave at present
mirrors the way people tend to use them, but the asymmetry is not
really justifiable.  I think the question here (why do we have branch,
push, pull and init all doing similar things) ought to be answered, or
probably even the larger question about what the single user model
should really be, rather than just posting a patch so that push can
create branches too.

-- 
Martin <http://launchpad.net/~mbp/>