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
