Most people don't use git particularly well. It's a capable piece of software that supports a number of different workflows, but because it doesn't mandate any particular workflow it's possible to use git productively for years without ever really touching some features.

And some of the features--in my experience mostly those related to more manual branching, merging, and history manipulation operations--are woefully underutilized. Part of this is because Github, which is responsible for facilitating much of git's use, promotes a specific workflow that makes it possible to do most of the (minimal required) branch operations on the server side, with the help of a much constrained interface. Github makes git usable by making it possible to get most of the benefit of git without needing to mess with SHA1 hashes, or anything difficult on the command-line.

That's a good thing. Mostly.

Nevertheless, there are a few operations that remain hard with git: I sometimes encounter situations that I have to try a few times before I get it right, and there are commands that I always have to check the man page to figure out how to specify the references. And even then I'm sometimes still confused. So maybe I (or we?) can spend a little bit of time and figure out what processes remain hard with git and maybe try and see if there is a way to make the process a bit more streamlined.

Here's my list:

• Reorder all commits since x commit.

  This is basically: find the commit before the earliest one that you want to change, run "git rebase -i <commit hash>" reorder the commits even though git sorts the commits in the order that I find most un-intuitive.

• Create local branches to track remote branches or repositories.

  Setup the remotes, if necessary, and then run: "git branch --track <local-branch-name> <remote>/<branch-name>" and "git config branch.{name}.push {local-branch}:master".

• Stash all local changes and switch branches.

  It would also be nice if you could figure out way for git (or a helper) to see any open files in your text editor and save/close them if needed.

• Pull a commit from the history of one branch into another branch without pulling anything else.

  I think this is chery-pick? It might also be nice to pull a series of commits from one branch, rebase them into one commit in the destination branch, and then commit that.

• Pretty much every time I've tried to use the merge command to get something other than what I would have expected to happen by using "pull," it ends tragically.

Reader suggestions:

• Put your process/procedural frustrations with git here.

How about we work on figuring out how to solve these problems on the "comments page" page.

I learned about artbollocks-mode.el from Sacha Chua's post, and it's pretty freaking amazing.

Basically, it does some processing of your writing--while you work--to highlight passive sentences and affected jargon.1 And that's all. There are some functions for generating statistics about your writing, but I find I don't use that functionality often. You can enable it all of the time, or just turn it on when you're doing editing.

After a few weeks, I've noticed a marked improvement in the quality of my output. I leave it on all the time, but I'm pretty good at resisting the urge to edit while I'm writing. Or at least I'm pretty good at picking up again after going back to tweak a wording. In general it's hard to keep more than a few things in an editing pass at any time.

It turns out that the instant feedback on passive sentences, even though it's not perfect, is great for improving the quality of my content the first time out. And it's even better for doing editing work. It's harder to ignore a passive sentence when the editor is highlighting you see a screen full of them for you.

It's of course important to be able to ignore its suggestions from time to time, and it's no harder to ignore than "flyspell-mode" (the on-the-fly spell checker in emacs.)

I'm not sure I'd fully realized it before, but the key problems in systems administration--at least the kind that I interact with the most--are really manifestations of a tension between complexity and reliability.

Complex systems are often more capable flexible, so goes the theory. At the same time, complexity often leads to operational failure, as a larger number of moving parts leads to more potential points of failure. I think it's an age old engineering problem and I doubt that there are good practical answers.

I've been working on this writing project where I've been exploring a number of fundamental systems administration problem domains, so this kind of thing is on my mind. It seems, that the way to address the hard questions often come back to "what are the actual requirements, and are you willing to pay the premiums to make the complex systems reliable?"

Trade-offs around complexity also happen in software development proper: I've heard more than a few developers talk in the last few months weigh the complexity of using dynamic languages like Python for very large scale projects. While the quests and implications manifest differently for code, it seems like this is part of the same problem.

Rather than prattle on about various approaches, I'm just going to close out this post with a few open questions/thoughts:

• What's the process for determining requirements that accounts for actual required complexity?

• How do things that had previously been complex, become less complex?

  Perhaps someone just has write the code in C or C++ and let it mature for a few years before administrators accept it as stable?

• Is there an corresponding level of complexity threshold in software development and within software itself? (Likely yes,) and is it related to something intrinsic to particular design patterns, or to tooling (i.e. programming language implementations, compilers, and so forth.)

  Might better developer tooling allow us to programs of larger scope in dynamic languages (perhaps?)

Reader submitted questions:

• Your questions here.

Answers, or attempts thereat ?on the discussion page.

I've been subject to a rather annoying emacs bug for months. Basically, when you start emacs with the --daemon switch, and the X11 session exits, and any emacs frames are open, then the emacs process dies. No warning. The whole point, to my mind, of the daemon mode is to allows emacs sessions to persist beyond the current X11 session.

This shouldn't happen. I think this is the relevant bug report, but I seem to remember that the issue has something to do with the way that GTK interacts with the X11 session and emacs's frames. It's something of a deadlock: the GTK has no real need to fix the bug (and/or it's a behavior that they rely on for other uses,) and it might not really be possible or feasible for emacs to work around this issue.1

I also think that it's probably fair to say that daemon mode represent a small minority all emacs usage.

Regardless, I've figured out the workaround:

.. don't use GTK.

Turns out, it's totally possible to build GNU emacs without GTK, by using the "Lucid" build. Which is to say, use the windowing system kit built for Lucid Emacs (i.e. XEmacs,) rather than GTK. I was able, using the code below, to get an emacs experience with the new build that seems identical2 to the one I used to get with GTK, except without the frustrating crashes every time that X11 spazzed when I decided to unplug a monitor or some such. A welcome improvement, indeed.

The following emacs-lisp covers all of the relevant configuration of the "look and feel" of my emacs session. Install the Inconsolata font if you haven't already, you'll be glad you did.

 (setq-default inhibit-startup-message 't
               initial-scratch-message 'nil
               save-place t
               scroll-bar-mode nil
               tool-bar-mode nil
               menu-bar-mode nil
               scroll-margin 0
               indent-tabs-mode nil
               flyspell-issue-message-flag 'nil
               size-indication-mode t
               scroll-conservatively 25
               scroll-preserve-screen-position 1
               cursor-in-non-selected-windows nil)

 (setq default-frame-alist '((font-backend . "xft")
                             (font . "Inconsolata-14")
                             (vertical-scroll-bars . 0)
                             (menu-bar-lines . 0)
                             (tool-bar-lines . 0)
                             (alpha 86 84)))

 (tool-bar-mode -1)
 (scroll-bar-mode -1)
 (menu-bar-mode -1)

Hope this helps you and/or anyone else that might have run into this problem.