[petsc-dev] close ts-fixes branch?

[Kai Germaschewski]

On Thu, Mar 25, 2010 at 12:00 PM, Lisandro Dalcin <dalcinl at gmail.com> wrote:

> On 25 March 2010 01:14, Kai Germaschewski <kai.germaschewski at unh.edu>
> wrote:
> > Fine with me (I'm the one who introduced it originally).
> >
> > My off-topic 2 cents: I hate reply-to headers.
> >
>
> BTW, I think this is an example of bad usage of mercurial branches...
> You should use a separate clone for these kind of tasks. Mercurial
> branches would make more sense for release versus development,
> although even PETSc does not uses this model. IMHO, creating a branch,
> push some fixes, merge back to default, and close branch is just
> repository pollution.
>

I actually disagree on this. The ts-fixes branch was a separate clone in the
beginning, actually. I did go through the efforts of separating this into a
sequence of patches, instead of having one "this one patch fixes all
approach", and whereas maybe for that particular case it could be considered
overkill, in general I consider it highly useful to break up changes into
pieces that can actually be verified by looking at them.

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

Both 1) and 2) have the disadvantage of introducing potentially lots of
merge changesets if development goes on for a while while head moves, too,
and one keeps the branch in sync. git handles this case by doing a "rebase"
instead of "merge" which keeps one's development clean (but one needs to be
careful with distributing things along the way, as history gets rewritten.)

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

--Kai




-- 
Kai Germaschewski
Assistant Professor, Dept of Physics / Space Science Center
University of New Hampshire, Durham, NH 03824
office: Morse Hall 245F
phone:  +1-603-862-2912
fax: +1-603-862-2771
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100325/b07b0271/attachment.html>