felipe.contreras at gmail.com
Fri Jul 11 12:36:20 EDT 2008
2008/7/11 Richard Laager <rlaager at wiktel.com>:
> On Fri, 2008-07-11 at 02:38 +0300, Felipe Contreras wrote:
>> A branch in git is merely a pointer.
> Likewise in MTN.
By pointer I meant a single pointer, to a single commit.
In mtn a branch is a bunch of commits that have a tag on them, a cert.
>> When you remove a branch you remove the pointer, not the commits in the branch.
Except that you can't just drop certs. Once pushed the branches stay
there. You can hide them, by adding another cert to the heads, but
they stay there.
>> You can consider a removed branch a suspended branch, it's hidden. If
>> you want to resume work on that branch you can create a new one, with
>> the same name, pointing to the same commit, so it's exactly the same
>> I believe what you call propagate is simply a merge. In git there's no
>> distinction between merging and propagating, it's called merge. If you
>> continue to work on it or not it doesn't matter.
> Likewise in Monotone. You can use explicit_merge if you want. The
> propagate command is just UI sugar ("porcelain").
> mtn propagate $source $dest ==
> mtn explicit_merge h:$source h:$dest $dest \
> -m "propagate from branch ..."
But there's a mental distinction. That's why I used the word "call". I
was trying to make clear that the use-case Gary was mentioning was a
common usage of branches in git; a merge.
> The above are all examples of where you simply don't understand
Why? Because I assumed branches in mtn are not pointers? (they
aren't). Or is it because I said, correctly, that a propagation is a
> I find it funny that you've railed against all the *good* parts of
> Monotone while missing the actual limitations that the rest of us have
> pointed out before.
> If you object to "mtn merge" and "mtn explicit_merge" being separate, I
> would support suggesting to the Monotone developers that explicit_merge
> be renamed to merge and if called with no arguments, it assumes
> arguments based on the current working copy to get the same results as
> "mtn merge" does now.
That's not a limitation, it's just cosmetics. It would be nice if that
gets implemented, but I wouldn't base a choice of SCM based on that.
More information about the Devel