<br><br><div class="gmail_quote">On Thu, Mar 25, 2010 at 12:00 PM, Lisandro Dalcin <span dir="ltr"><<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 25 March 2010 01:14, Kai Germaschewski <<a href="mailto:kai.germaschewski@unh.edu">kai.germaschewski@unh.edu</a>> wrote:<br>
> Fine with me (I'm the one who introduced it originally).<br>
><br>
> My off-topic 2 cents: I hate reply-to headers.<br>
><br>
<br>
</div>BTW, I think this is an example of bad usage of mercurial branches...<br>
You should use a separate clone for these kind of tasks. Mercurial<br>
branches would make more sense for release versus development,<br>
although even PETSc does not uses this model. IMHO, creating a branch,<br>
push some fixes, merge back to default, and close branch is just<br>
repository pollution.<br></blockquote><div><br>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.<br>
<br>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:<br><br>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...)<br>
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...<br>
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.<br><br>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.)<br>
<br>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...<br>
<br>--Kai<br><br><br><br><br>-- <br></div></div>Kai Germaschewski<br>Assistant Professor, Dept of Physics / Space Science Center<br>University of New Hampshire, Durham, NH 03824<br>office: Morse Hall 245F<br>phone:  +1-603-862-2912<br>
fax: +1-603-862-2771<br><br>