I moved my local Firefox changes between Git trees the easy way
Firefox recently officially switched to Git, in a completely different Git tree than their old mirror. This presented me a little bit of a problem because I have a collection of local changes I make to my own Firefox builds, which I carry as constantly-rebased commits on top of the upstream Firefox tree. The change in upstream trees meant that I was going to have to move my commits to the new tree. When I wrote my first entry I thought I might try to do this in some clever way similar to rebasing my own changes on top of something that was rebased, but in the end I decided to do it the simple and brute force way that I was confident would either work or would leave me in a situation I could back out from easily.
This simple and brute force way was to get both my old tree and my
new 'firefox' tree
up to date, then export my changes with 'git format-patch
' from the old tree and
import them into the new tree with 'git am
'. There were a few irritations
along the way, of course. First I (re)discovered that 'git am
'
can't directly consume the directory of patches you create with
'git format-patch
'.
Git-am will consume a Maildir of patches, but git-format-patch will
only give you a directory full of files with names like
'00NN-<author>-<title>.patch', which is not a proper Maildir. The
solution is to cat all of the .patch files together in order to
some other file, which is now a mailbox that git-am will handle.
The other minor thing is that git-am unsurprisingly has no 'dry-run'
option (which would probably be hard to implement). Of course in
my situation, I can always reset 'main' back to 'origin/main', which
was one reason I was willing to try this.
(Looking at the 'git format-patch' manual page suggests that what I might have wanted was the '--stdout' option, which would have automatically created the mbox format version for me. On the other hand it was sort of nice to be able to look at the list of patches and see that they were exactly what I expected.)
On the one hand, moving my changes in this brute force way (and to a completely separate new tree) feels like giving in to my unfamiliarity with git. There are probably clever git ways to do this move in a single tree without having to turn everything into patches and then apply them (even if most of that is automated). On the other hand, this got the job done with minimal hassles and time consumed, and sometimes I need to put a stop to my programmer's urge to be clever.
|
|