coreboot

git svn info: Unable to determine upstream SVN information from working tree history

If you ever had to work with a clone of a git repo which was created with git-svn, you might have tried to run

git svn info .

to find out about the latest svn revision in the git tree. Instead, you will see the error message

Unable to determine upstream SVN information from working tree history

and you might scratch your head. Turns out that git svn info only works for local trees created with git-svn. Once you clone such a tree, all svn related metadata will be lost. This data loss is by design. Apparently git considers svn info to be “metadata” which will not be cloned, whereas git history is not “metadata” and will thus be cloned. Is is also apparently fairly well known among git developers and advanced users that git svn only works from the repository it is initialized from, but the documentation doesn’t mention this limitation anywhere AFAICS. Similar issues exist for git svn log.

Continue reading git svn info: Unable to determine upstream SVN information from working tree history

CF iPod conversion to FAT32

In order to install Rockbox on an iPod, it needs to be formatted in FAT32, not HFS+. The relevant wiki page over at the Rockbox site suggest either connecting the iPod to an iTunes install on Windows, or using one of the bootsectors they have available for download from that page.

Those boot sectors assume your iPod has one of the factory disks installed. I’ve got an old 4th gen iPod that I converted to compact flash after its disk died. It happens to have an 8G CF card in there.

Since I don’t do Windows, I downloaded the 20G 4th gen bootsector, put that on the iPod, and used fdisk to change the size of the FAT32 partition. And that worked fine.

How to use the full size of your (x)term when connecting to some other box serially with minicom

Just as a reminder for myself, as I'll probably need this more often in the future (and maybe it's helpful for others):

Per default, if you use a big xterm (232x74 in my case) where you start minicom, the $COLUMNS and $LINES environment variables will be 80x24 nevertheless, and those applications which honor them (vim, for example) will be too small and not use the full xterm size of 232x74.

  $ minicom
  $ echo $COLUMNS; echo $LINES
  80
  24

You can fix that like this:

  $ eval `resize`
  $ echo $COLUMNS; echo $LINES
  232
  74

After you do eval `resize` the variables are updated and vim will use the full xterm size. That's all.