I get at least 50% of my work done on my Dell Mini 10v with the stock 1GB ram and an installed-by-me 60GB SSD running Ubuntu 11.10. My other computer is an i7-2600k running Win7 pro 64bit with 8GB ram, two 24″ monitors, a 120GB vertex2 ssd for a system drive, and a 2TB caviar black for a data drive. But I still like to use my netbook.

I would like a slightly bigger screen and dual cores in a netbook, though.

I looked at the Sony 11.6″ E-350/E-450 really hard, but I think I’ll pass. I’m spoiled by the silent operation of my netbook (the 10V is fanless).

I see Lenovo will be selling an 11.6″ dual-core Cedar Trail that appears to be fanless (no fan vents visible, only a bottom vent like on my Dell). I hope Intel releases Linux drivers for Cedar Trail by the time this Lenovo (the S200) goes on sale, if it is indeed fanless.

But whoa!, I didn’t know about hg fetch. Talk about implicit, not only does it implicitly merge, it even implicitly commits the results of the merge. (Ok, I imagine you’ll get prompted for a commit message, so you’re unlikely to do so by accident, but still… IMHO something as wacky as fetch should be an Hg extension so you have to explicitly enable it….)

roy

I’m probably being unfair in my complaint about implicit merges – all source code control systems implicitly merge into the working copy all the time.

But in source code control systems I have some familiarity with (SVN, a little Hg) the only merges that I can think of that happen without typing the command ‘merge’ happen when there are uncommitted changes in the working copy, and an operation is performed that updates the working copy (and hence has to merge those changes in). And AIUI that’s not what we’re talking about here.

There’s also something odd going on with command naming – why is it that a pull is not the opposite of a push? To have push and fetch be the actual direct counterparts, with pull being something different, is… unnaturual to say the least…

roy

I hadn’t realized this one before, not being familiar with Mercurial, but, indeed, it seems that “hg pull” is closest to “git fetch”, while “hg pull -u” (or “hg fetch” – aargh again!) is closest to “git pull”.

With regard to explicit / implicit, I dunno. I’d probably argue that using “git pull” is to explicitly request a merge as well as a fetch, since the summary in its man page says “Fetch from and merge with another repository or a local branch” (my emphasis). However, part of the point of this blog post is that a lot of newcomers to git don’t realize that you can do “git fetch” instead of “git pull” to avoid the automatic merge.

The thing that I might change in your definition of a merge to make it more “git worldview” is that (usually) merges in git are between two commits (and thus the state of two complete source code trees) rather than a file-by-file operation. (I say “usually” because you can merge between more than two commits (octopus merges), there are subtree merges, etc. etc.)

To me, a merge is when you take two different sets of edits to the same file, and try to combine the intent of the edits to produce a single resulting file. It is a process that can in some cases be performed automatically, and in other cases is impossible without (sometimes significant) manual work.

Are you saying that a “git pull” (unlike an “hg pull”) implicitly performs a merge (in the above sense) without it being explicitly requested? That sounds… surprising… Either I don’t get git yet, or I don’t get git yet. (Or maybe both. Which is fine. It took me quite a while to evn start to get Hg, too, and I’m still only in the “reading about” phase with git.)

roy


193 Load_Cycle_Count 0x0032 171 171 000 Old_age Always - 87811


… and it seems stable at the moment.