Why we didn't migrate to Mercurial (long)

[Ciprian Dorin Craciun]

On Sat, Oct 20, 2012 at 8:04 PM, Martin Geisler <martin at geisler.net> wrote:
> Ciprian Dorin Craciun <ciprian.craciun at gmail.com> writes:
>
>> On Thu, Oct 18, 2012 at 1:27 AM, Martin Geisler <martin at geisler.net> wrote:
>>> Ciprian Dorin Craciun <ciprian.craciun at gmail.com> writes:
>>> There is no system in place today that will let you:
>>>
>>> 1) later delete changesets locally
>>> 2) delete the changesets on the server
>>> 3) delete the changesets in other people's clones
>>>
>>> As far as I can see, Git gives you 1) and 2), but doesn't give you 3).
>>
>>     Partially true. For example Git allows you to remove changesets in
>> other people's clones next time they pull, **if and only if** they
>> don't have a non-remote branch referring to them, that is only if they
>> didn't base any work on them.
>>
>>     This happens like this:
>>     * I delete the branch locally;
>>     * I push the deletion to the server;
>>     * the user pulls and the remote branch gets deleted from his local
>> repository;
>>     * thus if he didn't tag or branch locally those changesets then
>> they'll be garbage collected some time in the future;
>
> Nice, I didn't know this! A lot things make more sense now :) I see how
> it's much easier to distribute commits for review purposes with Git:
> just push them to a shared server and others can pull them. When I
> update the server, the commits you originally pulled from me will go
> away automatically.

    As Arne asked, this "vanishing" only happens if you also specify
the `--prune` option to fetch. (Or you delete the remote, or branches
manually.)

    But indeed as you've observed this change review worklflow is what
I miss most from Git. For small projects (2-3 members) using a shared
repository is better than a patch mailing list (or an MQ extension,
etc.)

    Moreover this workflow is already the standard way to distribute
patches in GitHub / BitBucket (which we use): you have pull (in fact
merge) requests, not rebase requests. Thus not even BitBucket supports
rebasing from the web interface, even for Mercurial.


>>> Changeset obsolescence will give you 3) by letting you push the obsolete
>>> information to a server from where other can pull it. Nothing is really
>>> deleted, though, but changesets can be hidden when they've become
>>> obsolete. If needed, a garbage collection run can later delete them.
>>
>>     Thus we can say that this is on par with Git. Changesets will
>> disappear if the user didn't base some new changesets on the obsoleted
>> ones.
>
> The evolution work adds a bit more logic: if you've based work on a
> branch that I'm trying to delete, then it'll know (via the obsolete
> markers) where your changesets should be rebased to.
>
> Similarly, if we both edit the same published changeset, then the
> extension can detect this since there will be two obsolete markers
> pointing to the same changeset -- the way to resolve this is to merge
> the two changesets that both claim to be better.

    I don't thing Git has such a feature -- you have to figure out the
rebasing manually -- but I'm sure that if it is needed it will be
quickly added.

    Back to the feature it does make sense and I guess it's helpful
especially for very "fluid" projects. But as said for small teams I
don't think it adds much, as people prefer to merge than to rebase.

    Furthermore I'm curios how easy it is to explain this to a
beginner user of Mercurial. I mean I think there are the following
levels of "understanding":
    (1) pull+merge as one atomic operation / commit / push (a'la SVN workflow);
    (2) pull and merge as separate operations, single heads;
    (3) branches / bookmarks, multiple heads;
    (4) rebasing;
    (5) changeset stripping, history modification, etc. (a.k.a. plugin guru); :)

    Now I wonder where the average Mercurial user is? (Or any other
DVCS for that matter, including Git?) I bet somewhere between (2) and
(3).

    To my shame I've always tried to elude rebasing, and most of the
time prefer merging. (To the date I think I rebased at most 2-3 times
in Git, and I'm a heavy Git user for a couple of years now.)

    Ciprian.