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

Jed Brown jedbrown at mcs.anl.gov
Wed Jan 9 22:40:16 CST 2013


On Wed, Jan 9, 2013 at 10:28 PM, Sean Farley
<sean.michael.farley at gmail.com>wrote:

> 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.
>

I'm sorry I don't hang out on the hg development list. It's telling that
we're still getting hung up on things that were stable more than five years
ago in Git. Hg does get better (and more git-like) in each release.


>
> > 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.
>

That's a good idea. I was looking for another project.


> 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).
>

Git has unnamed "detached" heads, but I almost never use them because I
remember names better than SHA1s. But I have to be able to *trust* the
names, which Hg doesn't currently offer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130109/bbbbe82f/attachment.html>


More information about the petsc-dev mailing list