[petsc-dev] close ts-fixes branch?

[Matthew Knepley]

On Thu, Mar 25, 2010 at 2:09 PM, Kai Germaschewski <
kai.germaschewski at unh.edu> wrote:

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

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?


> 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

   Matt


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


-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100325/a62297a3/attachment.html>