2015-07-03
Wandering Thoughts is now ten years old
Because I am often terrible at scheduling, Wandering Thoughts' ten year anniversary was actually almost a month ago, on June 12th (for odd reasons). And as I noted four years ago, I'm not really for anniversaries. Still, ten years is something that feels significant, enough so to produce some words.
I'm a different person than I was ten years ago and four years ago, but then we almost all are. Some of the changes are welcome ones, some less welcome, and some just are. Wandering Thoughts too has undoubtedly changed over the ten years I've been writing at least one entry a day here, but those changes are usually less obvious to me. Hopefully they are overall for the better.
(When I go back to read old entries, especially very old entries, I feel somewhat ambivalent about the changes in my writing style that I think I see. I suspect that everyone does.)
If you'd told me at the start that I would still be writing Wandering Thoughts ten years later, well, honestly I might have believed you; I'm the sort of person who gets into habits and then sticks to them unless something big comes along to jar me out. Am I happy to have done this and to still be doing this? Yes, of course, or I wouldn't be doing it any more. Writing Wandering Thoughts has enriched my life in any number of ways, both in the writing itself and in the contacts and associations I've made through the blog, and I'd be a quite different person without WT.
(Sometimes I wonder a bit about what that other me would be like. It's kind of fun but also hard; WT's effects on me feel quite pervasive.)
I don't expect to stop writing here and I probably won't change how I do it; my one entry a day habit is quite well set by now (although I sometimes think about the potential merits of taking longer to develop and write entries; writing them in an hour or two has its limitations and drawbacks).
(The next vaguely significant waypoint will be 4,000 main entries. Don't expect a marker for it, though.)
(And yes, if I think about it, ten years of an entry a day is kind of a scary thing to contemplate. I don't even try to add up the total time and effort I've put into Wandering Thoughts in the past ten years; it's far too intimidating.)
Some notes on my 'commit local changes and rebase' Git workflow
A month or so ago I wrote about how I don't commit changes in my working repos and in reaction to it several people argued that I ought to change my way. Well, never let it be said that I can't eventually be persuaded to change my ways, so since then I've been cautiously moving to committing my changes and rebasing on pulls in a couple of Git repos. I think I like it, so I'm probably going to make it my standard way of working with Git in the future.
The Git configuration settings I'm using are:
git config pull.rebase true git config rebase.stat true
The first just makes 'git pull' be 'git pull --rebase'. If I
wind up working with multiple branches in repos, I may need to set
this on a per-branch basis or something; so far I just track
origin/master so it works for me. The second preserves the normal
'git pull' behavior of showing a summary of updates, which I find
useful for keeping an eye on things.
One drawback of doing things this way is that 'git pull' will now
abort if there are also uncommitted changes in the repo, such as I
might have for a very temporary hack or test. I need to remember
to either commit such changes or do 'git stash' before I pull.
(The other lesson here is that I need to learn how to manipulate rebase commits so I can alter, amend, or drop some of them.)
Since I've already done this once: if I have committed changes in
a repo without this set, and use 'git pull' instead of 'git pull
--rebase', one way to abort the resulting unwanted merge is 'git
reset --hard HEAD'. Some sources suggest 'git reset --merge' or
'git merge --abort' instead. But really I should set pull rebasing
to on the moment I commit my own changes to a repo.
(There are a few repos around here that now need this change.)
I haven't had to do a bisection on a
commit-and-rebase repo yet, but I suspect that bisection won't go
well if I actually need my changes in all versions of the repo that
I build and test. If I wind up in this situation I will probably
temporarily switch to uncommitted changes and use of 'git stash',
probably in a scratch clone of the upstream master repo.
(In general I like cloning repos to keep various bits of fiddling around in them completely separate. Sure, I probably could mix various activities in one repo without having things get messed up, but a different directory hierarchy that I delete afterwards is the ultimate isolation and it's generally cheap.)