[petsc-dev] close ts-fixes branch?

[Jed Brown]

On Thu, 25 Mar 2010 14:12:48 -0500, Matthew Knepley <knepley at gmail.com> wrote:
> > I actually disagree on this.

The problem is that mercurial named branches are "loud" in the sense
that they are visible forever.  This would be okay for something like
release branches, but they would all show up under hg heads which I
think is lame, and separate clones for releases is fine by me.

The closest thing to git's branches are hg "bookmarks" (you have to
enable the extension).  They are roughly equivalent locally, but
bookmarks are strictly local and have surprising (to me) semantics.
Read one of the tutorials and be careful (inspect what you have before
pusing, you can always clean up a local mess), they are capable of the
common things that git branches can do (within a single repository), you
just can't move them between repositories.  Git has no equivalent to
mercurial named branches (the branch name is never part of the
checksum).

> > So the way I see it, there are basically three ways to merge a change like
> > this (or any which is a sequence of patches) into the main repo:
> >
> > 1) do them in a separate branch, then merge that branch (and close the
> > branch, which I didn't but should have (mercurial used to not even support
> > this, a major shortcoming...)
> > 2) do them as a sequence on the top of head directly. Unfortunately, that
> > goes wrong if someone else changes head while working on the sequence of
> > patches. In that case, you end up with two branches which will merge with a
> > merge changeset. That's effectively the same thing as 1), branching and
> > joining, except that the branch doesn't have an explicit name, but I don't
> > really see the difference. If you guys don't like the explicit naming, I can
> > certainly adapt to that...

You can install the rebase extension (everything useful in mercurial is
under an extension, but fortunately they distribute the important
extensions with core these days).  I like to rebase for small-ish
changesets, unless my work is likely to conflict with whatever is
happening upstream (just to avoid every other patch being a merge).  If
my work does conflict, then I'll probably merge so that I don't risk
botching conflict-resolution in a rebase and having certain changesets
be broken.

> > 3) Just import the patch (with some manual trickery) into head as a single
> > changeset -- for obvious reasons, I don't think this is a good way, and
> > history is lost.

This is horrible, you might as well be using crap like subversion.

The fourth option is that you keep an extra head locally, until your
features are done/mergeable.  This is much easier to do with bookmarks,
(set track.current=True to get non-insane behavior).

> I do not understand what distinction is being made here. Doing a clone is
> cleaner than doing a branch, and I see
> no real benefit from the branch. Is there any?

If hg had git-style branches (like bookmarks, but not strictly private)
then it would provide an easy way to share work before merging.  This is
lower effort to create and look at than a separate clone.  Since this is
not available, and hg branches are so intrusive, a clone is the only
reasonable option if you need to share unmerged work.

> > Anyway, this probably shouldn't lead to a git vs hg discussion, but I've
> > used mercurial as my main tool for various things for quite a while, and
> > recently learned more about git, and for me it solves a lot of the annoying
> > little things I kept running into with hg. Including having a gui that let's
> > you go through changes before commiting them, and separating them, so you
> > don't need to do "can't remember what the heck I changed -- I wish mercurial
> > had a frontend like bk" commits. (By the way, even for hg there's "hg diff"
> > and "hg diff | diffstat" which helps...) I used to work on the linux kernel
> > with bk, so it's probably no surprise that git seems to support the kind of
> > workflow I'm used to, though...
> >
> 
> hg qct

I've mentioned this before, but qct has a pretty sorry interface for
partial commits.  TortoiseHG is definitely nicer in this regard.

hg view (aka. hgk) has a reasonable history browser, but it's way slower
than gitk.

Jed