Question

I use git rebase --onto target source foo to move the branch foo from the branch source onto the branch target. Do you know if it is possible to use hash values instead of branch names (if not given) like this: git rebase --onto ab91c f4242 foo?
As a workaround I temporarily added branch names to the relevant commit objects. But this can be a pita if you have many branches to being rebased.

Example situation:

° bb42a
° ab91c
° 979c2
          /° fb648 foo
° f4242 --
° 333c9

After git rebase --onto ...

° bb42a
          /° fb648 foo
° ab91c --
° 979c2
° f4242
° 333c9

Background:
The explained problem is very common if you use an svn-server as you remote repository. All you commit objects get rewritten since the svn-id will be added every time you git svn dcommit to the svn-repository. This detaches all other branches from their former master.

Answer 1

What is sure:

• a git rebase (not a git-svn rebase) can accept any valid commit as an argument, so hash values will work.
• The caveat section of git-svn does warn you of:

avoid all git clone/pull/merge/push operations between git repositories and branches.
The recommended method of exchanging code between git branches and users is git format-patch and git am, or just ‘dcommit’ing to the SVN repository.

So you need to make sure to not introduce commits in a SVN-synchronized branch which wouldn’t know about that commit and would report as such.
(you have the opposite case in the SQ question “git svn – <file> was not found in commit <hash>“)