Why can't git-rebase back up?

Newbie question... In what I assume is a usual technique, I maintain a "build" branch off of the linux-2.6 history which is what I check out to build a kernel. I usually keep it at an official tagged releas, such as v2.6.16-rc2.

[[ This is because core git won't allow the checked-out HEAD to point to anything but a branch, and checking out something without having HEAD point to it is fragile and delicate. Cogito lets you do this with cg-seek. ]]

Now, if I want to migrate to a newer base version, I can always use git-reset --hard v2.6.16-rc3, but that's a bit dangerous. Preferable is to use git-rebase v2.6.16-rc3, which will preserve any local edits.

(I could also do it as a merge, but that seems like unnecessary history clutter. It's not like local edits are common, anyway.)

But suppose discover a nasty bug in -rc3 and want to move my build branch back to -rc2. "git-rebase v2.6.16-rc2" does nothing. After a bit of thought, I realize why, but sometime I do want to back up.

What's the best way to do that? Should git-rebase take an optional third argument which is the branch head we are moving away from? E.g. what I want to do would be

	git-rebase v2.6.16-rc2 build v2.6.16-rc3

Or is there some other tool already suited to the job?

(Yes, I'm aware the operations cannot be exact inverses, because if I applied a local patch that was also included in -rc3, git-rebase will delete the redundant copy from the build branch, and the backing up will have no way to know to put it back. If I wanted to do that, I would use a merge.)

On a completely unrelated note, how do I find out what git thinks of a particular file, such as linux-2.6/.config? It isn't listed in the output of git-status or git-ls-files, but git-ls-files -i produces an error. Very confusingly, git-ls-files -i --exclude-per-directory=.gitignore -X .git/info/exclude .config also produces no output, even though .* is listed in .gitignore.