Recently I found myself in a situation where I wanted to bring in a specific upstream commit into a forked repository. Although these repos share a common history, the two repos had diverged enough that it wasn’t a straight-forward cherry-pick between branches. Instead, with clones of the two repositories I managed to cherry-pick as follows:
git --git-dir=..//.git format-patch -k -1 --stdout | git am -3 -k
To complicate things further, a few days later, I found myself wanting to do the same thing, however, this time a submodule and another file had diverged enough that the patch no longer applied correctly. To get around this I had to:
git --git-dir=..//.git format-patch -k -1 --stdout | patch -p1 --merge
Manually fix any of the still broken changes, then create a new commit with the changes.
These two stack overflow questions helped to work both of these issues out: https://stackoverflow.com/a/9507417 and https://stackoverflow.com/a/49537226
Finally, I’ve also in recent months found myself wanting to create a completely empty commit to kick off a downstream build process… much like you may touch a file to change its timestamp. To do this you can simply run:
git commit --allow-empty -m "Redeploy"
I’ve recently hit an interesting issue involving Docker containers and compiled C code crashing code with
illegal hardware instruction errors.
In a nutshell the Docker image was built on a server using Jenkins. It has been running fine until the underlying host orchestration software and physical hardware changed.
My solution has been to remove the build of the C code from the
Dockerfile and instead put in inside a script which runs when the container starts.
For my use case this solution will work, however, it will require the C code to be compiled every time the Docker container runs.
Digging a little deeper, it appears that the underlying root issue may be the use of the
march=native flag in the C code’s underlying Makefile.
A few posts on Stack Overflow (in particular, https://stackoverflow.com/questions/54039176/mtune-and-march-when-compiling-in-a-docker-image), suggest that removing this flag may make little difference to the run time of the compiled code. Which, again depending on the use case, may be a good option to try as well to resolve these problems.
I use a lot of open source software in my research and work.
In recent months I’ve been modifying the source code of some of open source repositories to better suit my needs and I’ve contributed a few small changes back to the DeepLearning4J and the Snacktory projects.
This morning I’m starting to work on a further patch for the DeepLearning4J repository and I needed to bring my local repository up to date before committing the change. However, at some point over the past few months the DeepLearning4J repository has been rebased and my fork of it will no longer merge.
The usual approach for fixing this is to use the command:
git rebase upstream/master
However, for me this produces an error:
git encountered an error while preparing the patches to replay
As a result, git cannot rebase them.
Despite trying on two different computers similar errors occurred.
As I didn’t want to delete my entire repository and create a whole new fork of the upstream master this is the approach I took to fix the problem:
Backup the current master into a new branch:
git checkout -b oldMasterBackupBranch
git push origin oldMasterBackupBranch
Switch back to the master branch and replace it with the upstream master
git checkout master
git remote add upstream url/to/upstream/repo
git fetch hard upstream master
git reset --hard upstream/master
Push the updated master my github fork
git push origin master --force
This StackOverflow question helped a lot in working out this problem: Clean up a fork and restart it from the upstream