Wandering Thoughts archives

Why version control systems should support 'rewriting history'

There's a hot debate about whether VCSes should allow developers to 'rewrite history' (in the git sense). The usual way to frame the options can be wrapped up as a question: should the VCS allow developers to rewrite history, or forbid it? Put this way, a fair number of people will incline towards 'no'.

But this is a misleading and wrong question, because it quietly assumes that the VCS can actually stop people from rewriting history. This is incorrect; no VCS that has branches and lets developers apply patches can stop them from 'rewriting history' by hand if they want to badly enough. (This especially applies to DVCSes, where you can clone repositories outright and then throw away clones you don't want.)

So the actual choice that we have is this: should the VCS provide convenient support for letting developers rewrite history, or should it refuse to help and force them to do it all by hand?

As it happens we already know that developers are going to do this, one way or another; they do now to such an extent that there are various programs to help them with it (and I'm not talking about DVCSes that already support this). Since it's going to happen anyways, having the VCS support it has three advantages:

• you can give developers as much help as possible with what is a tediously annoying and potentially tricky operation.
• you can capture information about what actually going on.
• you may have a chance to gently steer developers away from bad ideas, provided that you can give them a good alternative.

By contrast, the VCS washing its hands of the whole deal means that it is abandoning the developers and abrogating any chance it might have had to mitigate damage or do any good. (But you get some mathematical purity out of it; my views on that are on record.)

Convenient ssh in Gnome, or 'my sshmenu wish comes true'

It turns out that I can get something that more or less does what I wanted sshmenu to do (per yesterday's entry). In email Dan Astoorian pointed me at the Gnome 'Command Line' applet and that it has macro capabilities; you can define a pattern and a command to run (using bits of the pattern) when the pattern matches the 'command' that you type. Thus, you can hijack it into a 'ssh session launcher' with suitable patterns.

The current patterns and commands that I've set up are:

(The RedText profile just has a foreground colour of #FF4500 (the classic X 'OrangeRed' colour value) instead of black, so that my root sessions stand out.)

This is actually better than just having a sshmenu text widget that I can type hostnames into, because I get significantly more flexibility. It helps that I already do something similar to this in my regular environment and actually like this peculiar form of mini-commands.

(If I was trying to make Gnome my normal environment I'd put all of the intelligence in a script and just feed all of these patterns to it, because it's much easier to make a script be super-smart than some regular expression matches, but that's too much setup work for what is really supposed to be quick customizations.)

I may well be doing this wrong (although it seems to work) or in a way that could be done better. In the usual Gnome style, the Command Line applet's macro stuff is underdocumented, with specific details about things like macro matching order and the like being notably lacking.