Monotone analysis

[Felipe Contreras]

Hi Gary,

On Thu, Jul 10, 2008 at 4:39 AM, Gary Kramlich <grim at reaperworld.com> wrote:
> Felipe Contreras wrote:
>> Hi,
>>
>> Regarding the multiple "mutable history is not an option for us".
>>
>> I sent a couple of patches, and I received some comments, so I was
>> expected to modify the patches, isn't that mutating the history?
>> Imagine the patches where in my mtn repository, and somehow I'm able
>> to fix them, and send them again. The maintainers shouldn't care about
>> how the patches where created, just that they are ok.
>
> If the patch was provided as a pull from your database that you served
> via mtn serve for us to grab the revs then yes, there wouldn't be any
> mutating of history.  Since your patch was never in mtn which is the
> location of the history that shouldn't be mutated, there was no mutation.

That depends on your definition of history. Is history only the
commits that make it into mtn? Is history only the commits that get
pulled into the repository of one of the maintainers?

>> So mutable history is not an option for maintainers, but it is the
>> only option for contributors without commit access, at least when
>> there's reviewing and changes needed.
>
> See above
>
>> Quoting Linus [1]:
>> "a grunt should use 'git rebase' to keep his own work in line. A
>> technical manager, while he hopefully does some useful work on his
>> own, should strive to make _others_ do as much work as possible, and
>> then 'git rebase' is the wrong thing, because it will always make it
>> harder for the people around you to track your tree and to help you
>> update your tree."
>
> So where do we fall?  Are we the grunts or you?  Either way doesn't
> matter, we're all least attempting to do work.  The amount of work
> should not determine which workflows should be used.  To me, it sounds
> like git-rebase was added to shut people up that spaz out when theres
> too much divergance in the history, and make it look more like a CSCM.

No, rebasing happens in mtn too, when you review patches and ask for
changes, the patch should apply into a head, right?. The only
difference is that git provides tools for doing that, while with mtn
you are on your own.

> <snip>
>
>>>> You can't cherry pick commits from a remote branch.
>>> mtn help pluck
>>
>> That's from the same repository.
>
> Not if you pull the remote branch in, which is how it's supposed to be
> done in monotone.

I see.

>>>> In mtn is all or nothing.
>>> in mtn we read all the documentation
>>
>> I was arguing that you don't have control over what happens.
>
> To clean up commits made by someone else, would be mutating the history.
>  Which as I'm sure you know by now, that is not something we want.

Do you always apply patches exactly are they are sent to you? If you
do some changes then you are mutating the history, at least according
to some definition of 'history'.

> <snip>
>
>>> Local branches are possible in mtn as well, you never push them.  When
>>> you want to move all your commits from a local branch to a "remote"
>>> branch, propagate and push the remote branch.
>>
>> Sure, but a local branch that you can't rebase isn't that helpful.
>
> Why is not being able to rebase unhelpful?

It's helpful, but it's much more helpful to rebase it.

With git-rebase you can do more than just rebase. If you do a commit
a, and later on you realize that you screwed up, so you do a fix
commit a, later on you can do "git rebase --interactive" and squash
the two commits into one, you can reorder your commits, edit them,
drop them, etc.

I can hear you saying again "we don't want mutable history".

Let's do a thought experiment. You have the real repo in A, and you
have a utility repo in B. In A you have non-mutable history, just like
in mtn, in B you have mutable history. You have a temporal branch on
B, which you rebase constantly squash commits, re-edit them, reorder,
etc.

Once you are happy with the commits you would want them into repo A,
but if you really think B is tainted since it has mutable history,
then you use git to create patches, and you email those patches to
yourself, and then you download those patches, and apply them into
repo A.

Applying patches is not mutating history, right? So git-rebase can be
used with repos that don't have mutable history.

> <snip>
>
>>> mutable history isn't an option for us.  We *WANT* to know about the
>>> branch even if it's not used anymore.
>>
>> All the commits of the branch are still there, it's just the pointer
>> that disappears. You would see it as a microbranch merge.
>>
>> It's not mutable history.
>
> So you want to "hide" the history?

What history? You merged branch "foo" into master, if you remove
"foo", all the commits would still be there, the merge would still be
there, even the name of the branch would still be there because by
default the message of a merge is 'merged foo'.

So what is missing? A pointer to "foo" right? But if you are not going
to use "foo" anymore what's the point of having it? No history is
lost, you can even create the pointer later on if you miss it so much.

> <snip>
>
>>> On occasion can be, damn this app I use every day is consistently
>>> crashing, I need to fix it.  Which to me, is serious development.
>>
>> s/serious development/constant contribution/
>
> I still disagree.  On another project I'm working, we're using svn.  I
> absolutely despise svn, possibly more so than you do mtn (if that's
> possible).  But we're using svn, because it's what everyone else knows
> and understands.  The level of support I don't have to provide more than
> makes up for having to use what I find a obsolete tool.

Perhaps. In any case I personally prefer svn over mtn, even cvs.

>>>>>> There's a reason why nobody is using mtn: it's not ok.
>>>>> And again you spout an _opinion_ that you haven't supported with any
>>>>> real, irrefutable evidence.  If you want to bitch about monotone, go
>>>>> bitch to its developers.  I'm tired of seeing your complaints about our
>>>>> decision on what tool to use.  If you can't handle that, tough.
>>>> I would like to hear another theory about why nobody is using it.
>>> How's this?  People think Linus knows best in every situation?
>>
>> That doesn't even make sense. Bazaar is quite popular too and git
>> isn't even maintained by Linus, people disagree with Linus on the git
>> mailing list too. And there's also mercurial. Those are used.
>
> For the record, that was tongue in cheek.  The point I was alluding to,
> is that I can't believe you're going around telling every project that's
> not using git to go and use git, or even every project that's using
> monotone to go and switch to git.

Actually none of the projects I participate in use git, I'm perfectly
fine with svn/cvs/bzr. The only tool I can't stand is mtn.

> But that wouldn't be right either.  At any rate, I get it.  You have an
> itch to scratch, you want to work on msn, you don't like mtn.  That's
> fine, luckily plugins can easily be developed out of tree.  Or if that's
> not an option use tailor to export our mtn to git, and if need be, git
> back to mtn.  Or is tailor just another crappy tool?

Yeah, tailor is crappy. It will create a single branch out of the mtn
tree and convert it to git. Just like mtn->svn->git. And even with
crappy messages like: [foo-migrate @ whatever].

In case you didn't notice I created a tool that converts a mtn repo
into a git repo, preserving all the history:
http://pidgin.im/pipermail/devel/2008-June/006125.html

>> I don't have to work with mtn.
>
> see above
>
>> In other tools you see: merged silly_fix. In mtn you would have to
>> open a visualization tool just to see what the hell that merge
>> 239247130283 into 85938403482 meant.
>
> Right, and when you open said visualization tool, it'll load up
> everything just once, and look, you have all your history there that
> saves you're precious 8.5 seconds more that it took to do an mtn merge.
>
> <snip>
>
>> I was talking about John Bailey.
>
> So you're trying to make a technical discussion personal, interesting...

No. he seems to take this personally, I was just pointing that out.

Cheers.

-- 
Felipe Contreras