[petsc-dev] [mpich-discuss] MPICH migration to git

[Sean Farley]

On Wed, Jan 9, 2013 at 10:17 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Wed, Jan 9, 2013 at 10:03 PM, Sean Farley <sean.michael.farley at gmail.com>
> wrote:
>>
>> * branching
>>   - git has light-weight branches (this means that the branch metadata
>> is not written in the changeset)
>>   - mercurial calls these things bookmarks
>
>
> Bookmarks have always been an extension that you have to explicitly enable
> (along with color, pager, graphlog, etc).

Not true after version 2.2 (or 2.3?). Bookmarks are enabled by default.

> Branches, which most people agree
> are bad design and don't use, are there by default. Quite importantly,
> bookmarks are *fragile* in that they can move around indirectly as a
> side-effect of an operation that does not directly reference the bookmark.
> Worse, when that happens, there is no way to recover the metadata.

I've found most of your bugs in the mercurial tracker. Almost all of
your use cases that you are referencing are solvable after the
introduction of evolving changesets. The key feature missing was the
ability to mark a changeset as 'killed' or 'invisible' or whatever you
want to call it. `hg strip` would really remove the changesets and
therefore the bookmark would no longer have anything to point to. Now
that changesets can be hidden, your gripes are moot. The bookmark will
stay there and can be restored easily.

This is a great example of comparing an old version / concept of
mercurial with git.

> (It is
> ironic that the system written in a garbage-collected language does not have
> garbage collection while the system written in C has garbage collection.)

Evolution will take care of garbage collection.

>> The important thing to remember about using mercurial branches is that
>> they are just like svn (i.e. permanent). So, if you're looking for a
>> light-weight branches then simply use mercurial's bookmarks. You might
>> as well forget about the `branch` command if want to compare to git.
>>
>> Unfortunately, Jed is right that bookmarks have some rough spots but
>> 1) it's finally being dog-fooded and 2) development with branches /
>> bookmarks in mercurial will be much better after changeset filtering
>> is implemented (which looks like it was pushed to crew today,
>> actually). I haven't seen any problems using bookmarks in my everyday
>> workflow, especially with evolution.
>
>
> They've had more than five years of yet-another-branch-like-thing.

Odd. You've had more than five years to fix it yourself.

>> * user interface
>>   - git has notoriously had a bad interface and even when I think some
>> command will do what I want, it somehow messes up
>
>
> Familiarity. Both have quirks.

Bah. Mercurial's interface is much, much cleaner.

>>   - mercurial has a pretty clean interface for the most part (and more
>> importantly) makes typing shorter commands possible
>>
>> * speed
>>   - tough to really say now that Bryan O'Sullivan's patches are in
>> mercurial and he's actively working on that front (for Facebook … who
>> still uses subversion)
>>
>> * mutable history
>>   - git decides this based on whether there is anything "pointing"
>>   - mercurial decides what is rewritable by the phase (public, draft,
>> secret)
>>
>> This last bit of mutable history is what I've found to be an
>> indispensable workflow. I haven't seen any comparison of this
>> mercurial feature with modern git (to be fair, it's with a develop
>> version of mercurial).
>
>
> Phases are like having a terminal that automatically locks when idle for 1
> minute. Sure, it's "safer", but it's more time fiddling with the lock.

You're confusing phases with evolution. It is true that phases are
needed to mark which changesets are mutable without which there is no
way to know which changesets have been shared or not. Git solved this
by not allowing anonymous heads. Mercurial did this by having the
concept of a "publishing" repository (i.e. are changesets pushed to it
are marked public).