Monday, March 7, 2016

Using git-stash without losing staged changes

When I learned about git-stash, my productivity with git from the command line went way up. But it wasn't until recently that I figured out how to properly handle the situation where I had already staged changes but needed to stash everything to do something without .

The problem comes from the fact that stash lumps all the changes to the tracked files together, without separating all the things you've added to the index. If you've done a patch add with git add -p, this can mean a lot of frustration at having to pick through all the changes again once you do git stash pop.

To avoid this frustration, do the following and you'll be able to keep your staged changes over the course of using stash.

1. First, do a stash of only the things you haven't yet staged:
git stash save --keep-index "Un-staged changes"
At this point, if you run git status, you should see all your changes that have been staged still there, but none of the changes NOT staged for commit (except of course for any untracked files).

2. Next, stash the staged changes as you normally would:
git stash save "Staged"

3. Now is when you want to do any work you need to while the other changes are stashed. NOTE: If you need to make changes that are based on a file in the "Un-staged changes" stash, you will of course need to pop that stash specifically with git stash pop stash@{1}. But, in order to get the staged changes back, you'll need to do another git stash save to do things in the correct order.

4. To get your changes back, you're going to pop them off the stash in the reverse order. If you haven't stashed any other changes, you can do a simple pop:
git stash pop
Otherwise, you should run:
git stash list
and find the correct name of the stash to pop, e.g. stash@{1}.

5. All the changes you just popped aren't staged at this point but should be, so go ahead and add all of them to the index with git add file1 file2 ...

6. Finally, run git stash pop one more time to recover the un-staged changes you saved in step 1 and you'll have everything back to the way it was at the beginning.

Friday, February 26, 2016

How to check out an old version of Chromium OS

You gotta love the combination of open source projects and git. Getting up and running with a project like Chromium OS is pretty straightforward with the guide available on the Chromium Wiki. But what if, for some reason, you're interested in a version other than the most recent? How do you dig through the combinations of repositories to get it? I recently had to figure this out for a project I'm working on, so I thought I'd pass it along.

First off, you should know that version numbers between Chrome, Chrome OS, Chromium, and Chromium OS do have a certain correlation, but isn't guaranteed to be the same across the repositories for all of them.

Once you've figured out which version of you want, go to https://chromium.googlesource.com/chromiumos/manifest-versions/+/master/paladin/buildspecs/, click on the version number in the list, then select a build number from the next page.

What you see next is a long XML file that tells repo (Google's wrapper around git) what versions of all the Chromium repositories correspond to that build number. Scroll all the way down to the bottom of the page and click on the "txt" link to download it. This will be a Base64-encoded version of the XML file you were just looking at.

Next, decode the text file with a command like this:
base64 -d [manifest_version].txt > [manifest_version].xml
This assumes you're working on a *nix system. A quick Google search will help Windows users. Be sure to replace [manifest_version] as appropriate.

Assuming you've checked out the Chromium OS repositories before using the repo command, run the sync command using the manifest you just downloaded with:
repo sync -m /path/to/[manifest_version].xml
If you haven't checked out the repositories before, follow the instructions on the guide listed above, then replace the repo sync command with the one above. Keep in mind that the sync process takes a VERY long time.

At this point, if you were to try and enter the SDK with the usual cros_sdk and do any commands, they would likely fail because it is too new. Get the appropriate version with:
cros_sdk --replace
This command will also take a long time to complete.

Now you can enter the SDK with cros_sdk. Now you should rebuild all the packages with:
build_packages --nowithdebug --board=${BOARD}
This command will also take a long time to complete.

Finally you can build an image with the usual command (adding any extra flags you need):
build_image --board=${BOARD}

That's it! Good luck working with Chromium OS!

Monday, January 18, 2016

Getting "n-dimensional" to look right in LaTeX

LaTeX has some interesting rules for dashes and hyphenation that are hard to get right in certain scenarios. For example, if you use the term "n-dimensional" and it happens to fall near the end of a line, you'll end up with something like this:
text text text text text n-
dimensional
To get this right, try inserting this snippet in your document's preamble:
\usepackage{amsmath}
\renewcommand{\ndimensional}[1]{#1\nobreakdash\discretionary{-}{-}{-}\hspace{0pt}dimensional}
Then, replace "n-dimensional" in the document with the following:
\ndimensional{n}
or, to get the math environment look to the "n", do this:
\ndimensional{$n$}

What's going on in the snippet?

The #1 refers to whatever you added as a parameter to the command, which in the example above is "n".

The \nobreakdash needs to be combined with a dash character. That means that in other situations you may just need to do this:
\renewcommand{\ndimensional}[1]{#1\nobreakdash-\hspace{0pt}dimensional}
While the output will be fine for many use cases, the previous snippet with the \discretionary command is a more general-case solution. (See this forum post for more info.)

The \hspace{0pt} tells LaTex not to allow any space (including a newline) between the previous character and the one that follows, acting like glue between the dash added with the \discretionary command and the "d" of dimensional. Without it, you'll get output like this:
text text text text text n-
-dimensional

Edit: Turns out you need the amsmath package for LaTeX to know what the \nobreakdash command is. I've added the necessary command.

Friday, January 30, 2015

Fixing repo init to check out Chromium OS code

Building Chromium OS is a little tricky. Although the instructions from the project page are pretty detailed, one bump I ran into was this error when I put in the "repo init ..." command:
fatal: Cannot get https://chromium.googlesource.com/a/external/repo.git/clone.bundle
fatal: HTTP error 401

Turns out that there's an issue with in the repo init code that makes it fail if there's anything wrong with your ~/.netrc file. My system didn't even have a .netrc file, which made it hard to know how to fix that problem.

Saturday, October 19, 2013

The Last Straw for Excel?

Microsoft Office and I haven't been getting along well lately, which is too bad because I have really liked all the new features of Office 2013. But after upgrading Windows to 8.1 this week, Excel decided to stop working. As in, it completely crashes whenever I try to go beyond the view of cells available when it opens. Not cool.

Normally I'd try to figure something out to get everything working, but this weekend I had to input my students' grades so I could discuss their test scores with them on Monday, so I didn't have time to go on a wild Windoze chase for a solution. Instead, I tried out the import feature of Google Docs, and overall I was pretty impressed. Let me share the details...

Wednesday, May 8, 2013

Getting into Developer Mode on the HP Pavilion 14 Chromebook

So I recently added the HP Chromebook to my cohort of tech gadgets, and naturally wanted to put the device into developer mode. While the information posted on the Chromium Wiki about the HP Chromebook was helpful, it turns out that it is incomplete. So below the break are my abbreviated instructions for getting it into developer mode from start to finish. Another great resource is the HP repair manual, available here.

Wednesday, November 7, 2012

Downgraded to Python 2.7.1? How did that happen?

So I was doing some work on my home computer tonight which involved a little bit of Python hacking in Windows.  At one point I wanted to make sure that I had a certain library installed such that it was accessible to the script I was working with, so naturally I opened up an interpreter and tried importing it.  It failed, which surprised me since I had just finished using pip to install it and no errors occurred.

The script I was working with was one I wrote a few years ago, so my first thought was that maybe they released a newer version of the library with different capitalization.  Kind of a strange guess, I know, but not too far-fetched considering PEP 8 is still not completely followed by the community and some maintainers of certain libraries are changing this to conform to the standard, but I digress.  I run the pip install command one more time, just to make sure that there wasn't an issue with naming.  Nope, dependency already resolved.

Finally, I noticed that the interpreter I was running was Python 2.7.1.  Well, I knew that couldn't be the problem, but I like to always have the latest version of Python installed so I thought I'd take a minute to rectify that.  But that was another issue... why wasn't I running 2.7.3?  It was weird that I had such an old version running when I'm usually so on top of updating Python.  Whatever.

So I first tried a repair.  Still showed up as 2.7.1.  Downloaded a fresh copy of the installer and verify the checksum.  Still showed up as 2.7.1.  Removed it completely after making a backup of site-packages, then re-installed it.  Still showed up as 2.7.1.  Uninstalled it again without re-installing it.  The interpreter still ran and showed up as 2.7.1.  What the...?

I was starting to get fed up at this point.  The system path didn't have anything out of the ordinary, like a separate folder for an old installation, nothing.  Finally, I found this StackOverflow article which, oddly enough, had an example of exactly what I needed to figure out what was going on and where this rouge installation of Python was that was driving me crazy. Here's what I got:

C:\Users\Mike>for %i in (python.exe) do @echo %~$PATH:i
C:\Program Files\Box Sync\Python.exe

Box Sync includes its own Python interpreter?  That's what's going on?  And it somehow became the default interpreter instead of my 2.7.3 installation?  Okay... I guess that's great they're using Python, but why force my computer to use an old interpreter?  I'm no Windows expert, but it seems like there should be a better way to do whatever it is they're trying to do.  But I can also have sympathy for them not wanting to use Py2Exe... shudder

Apparently, this is something Box is already aware of, but the whole thing is still just so weird.  I don't use Box that much as it is, so I think I'll just nuke their version of Python for the time being.  And yes, it did fix my problem.