rlaager at wiktel.com
Fri Jul 11 11:46:09 EDT 2008
On Fri, 2008-07-11 at 02:38 +0300, Felipe Contreras wrote:
> A branch in git is merely a pointer.
Likewise in MTN.
> When you remove a branch you remove the pointer, not the commits in the branch.
> 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 ..."
The above are all examples of where you simply don't understand
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.
> I saw the code in tailor, and I tried to improve it, however the
> design is flawed. Trying to make it replicate the exact topology would
> require to make it tailor2; a completely different tool.
From what little I know about it, I'd probably agree. I think they
removed the ability to go from a DVCS -> DVCS and keep the structure
some time ago (presumably it didn't work well or something).
> Also, it
> doesn't even work for the simplistic use-case that it's supposedly
> supporting right now, at least with git.
In my experience (and I realize yours may have differed), it generally
works pretty well, as long as you're willing to linearize history
completely (which sucks, I agree).
> Besides, there's no reason for such a tool, there are much more
> effective tools to communicate between git-bzr, git-svn, bzr-git,
> bzr-svn, git-cvs and bzr-cvs. I don't see the point of tailor.
The point of tailor would be to avoid having to write N^2 tools (one for
each pair). I'm not saying that is or isn't achievable or the most
efficient way to do things, but that's the design goal.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the Devel