Lately I’ve been converting a Subversion repository to Git using git-svn. The conversion is a breeze, you just need time.
$ mkdir killerapp
$ cd killerapp
$ git svn init -t tags -b branches -T trunk https://mysvn.com/killerapp
Initialized empty Git repository in .git/
$ git svn fetch
So now you have a working Git repo, fine. The only concern is how git-svn handles tags. Each SVN tag is converted into a branch, not a tag. For instance, tag 1.2 becomes git branch tag/1.2. git-svn might have a good reason for doing it but this is a bit disturbing to me, especially when you have dozens of tags polluting your ‘git branch’ output.
So I intended to convert all these branches into real tags, and delete them. Here is the command I came up with:
$ git-for-each-ref refs/remotes/origin/tags | cut -d / -f 5- |
while read ref
do
git tag -a "$ref" -m"say farewell to SVN" "refs/remotes/origin/tags/$ref"
git push origin ":refs/heads/tags/$ref"
git push origin tag "$ref"
done
If you happen to get an error like Can't locate SVN/Core.pm when running git-svn on a redhat, simply install the package subversion-perl.
While browsing the Git Community Book, I came across another great Git command: git-filter-branch. This command is a good way to edit commits en masse. The command gives you access to commit information and let you do whatever you want with them.
Here is my use case: every new feature I code for ODE has a JIRA id. It’s a good practice to mention this identifier in your commit messages, so that people can quickly know which issue this commit refers to, and eventually consult the JIRA page to get all the information related to it. Some tooling might even be built around this simple practice: for instance JIRA will index all the commits refering to a given issue.
Back to our case, so as I develop this new feature on my local Git branch, it happens that this JIRA id is rarely in my commit messages. Either because I forget, either because at the time of the commit I’m thinking to squash it later, etc. So when it comes to push these commits, I need to rebase my branch in interactive mode and manually edit each commit to prepend the JIRA id. Quite painful actually when you have a dozen of commits.
git-filter-branch makes that job in one single command:
$git-filter-branch --msg-filter "sed -e 's/.*/ODE-415: &/'" HEAD~8..
The argument is evaluated in the shell with the original commit message on standard input; its standard output is used as the new commit message. Nice..
No need to say that git-filter-branch should be use with care. The original refs, if different from the rewritten ones, will be stored in the namespace refs/original/.
The “Downloads/Multimedia” page of the ACLU has a section named “Know Your Rights”. As a non-citizen being living in the US for only 10 months, I’m not really aware of US-specific rights. You can even download and print a pocket card memo.
This was highly informative to me mainly because it validates everything I learnt in american police tv shows. To sum up: find a lawyer asap, keep his phone number with you at all time, call him before telling the police anything.
Six weeks ago Google added text ads at the bottom of Google Maps, now it’s Google Finance turn. Today during my lunch break some text ads appeared at the right top of Google Finance. It’s really intrusive: one quarter of the page width, exactly where the graph used to be. Your eyes can’t missed it because this is where you taught them to look in the first place! :( Don’t be evil…
I haven’t tried to figure out how they generate the content of these ads, is it based on your stock portfolio? on your searches? is it uncorrelated with your profile? I doubt it.
Usually I do my best to stay away from XML/XSD/Namespace puzzles. But today, I couldn’t escape it, my minimalist-but-yet-effective xml knowledge got challenged. And that’s really not the kind of challenge I like.
Here is the problem. I couldn’t understand why the following XML document does not validate against the given schema.
Something went wrong.
After some investigations and with some friends’ eyes, we figured out that the elementFormDefault attribute was the cause of our troubles. In the XML document the element is in the “ode” namespace but the XML schema sets the elementFormDefault attribute to unqualified. As Michael Kay put it, it “means that you want locally-declared elements like [reason] to be in no namespace.”
Even if “unqualified” is the default value, in most schemas, elements are qualified and I didn’t pay attention to that detail :/
So how does a valid document look like? One could be:
Something went wrong.
There is no default namespace, so unqualified elements default to no namespace.
Another valid instance document of that schema may look like:
Something went wrong.
The xmlns=”" declaration overrides the previous default namespace.
This article discusses in more details the raison d’être of qualified/unqualified elements.
I am still to be convinced that unqualified elements could be useful, but now I know that Axis2 generates schemas with unqualified elements and for now on I will make no assumptions on the value of that attribute!
ps: if you know why the XML names get down-cased by the Google syntax highlighter for Wordpress, drop me a line please.
In case you’re still thinking REST is only about HTTP, the following article InfoQ: How to GET a Cup of Coffee. is a must-read. Through a real life workflow example, the authors illustrate what “Hypermedia as the engine of application state” really means.
It’s dated October 2nd, so forgive me if you have already read it, I’m catching up on my to-read backlog.