Closed bjacquin closed 3 years ago
I am unfamiliar with git am
honestly. Not sure how much of a learning curve would be required to be functional with it vs what I am doing now.
The learning curve is pretty anecdotal to be honest and would actually help you keep your work up to date while upstream is making continuous changes. The diff itself would not change, but only the envelope format which specific headers created by git itself, while not affecting how the patch is applied, people can continue to use git apply, patch -p or git am.
Assuming you have a clone of linux kernel tree in your machine along with all your changes on top of HEAD, simply commit your changes, you can generate a git am patch by running git format-patch origin/master
(with options to place it in the right directory for kernel_gcc_patch). Once upstream has publish new release, you can simply pull and apply all of your changes on top by running git pull --rebase
. Of course, this can be applied on many branches as you wish.
Any guide you recommend?
This link explains pretty well how to create a git patch: https://kernelnewbies.org/FirstKernelPatch (See Creating a patch) This link has more information about applying a git am patch: https://kernelnewbies.org/KernelBuild (See Patching your kernel)
And also, the usual git official documentation which both contain good examples section.
If you want, I can help you to make such patches. It is basically very easy. For kernel 5.9 and GCC 10.1 I have one.
I'll look at the links when I have some time. Is it basically forking linux.git and maintaining a branch that carries the patched code and periodically rebasing it against the mainline code?
Correct, and using git format-patch to provide patches in this current repository
OK, I am familiar with that. Tell me again though how git format patch -1
would be any different to the end user? You're still patching mainline code.
Right, the main advantage is to able to use git am
when applying the patch to keep the git commit author and date, and ease the introduction of this specific patch is larger patch serie. And so to avoid merging incorrect changes when the current state of the git repo is dirty
OK, I think I understand. I will look into it.
So help me out here... I already have a fork of the linux tree I use for generating patches against the Arch Linux kernel for linux-ck. My .git/config
looks like this:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git://git.archlinux.org/linux.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[remote "stable"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
fetch = +refs/heads/*:refs/remotes/stable/*
[remote "zen"]
url = https://github.com/zen-kernel/zen-kernel.git
fetch = +refs/heads/*:refs/remotes/zen/*
I guess I can add a new branch to this pointing to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
? Call it "upstream"? Is that going to save me any disk space knowing that I am already doing this:
git pull --ff-only
git fetch --tags stable
git fetch --tags
git format-patch v"$v"..v"$v"-arch"$a"
When Arch updates
OK I did what I described above. Is https://github.com/graysky2/kernel_gcc_patch/commit/98c0a7fbcd0721b4e95e9305ed13b6000ee26e62 what you're asking for?
git remote add upstream https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch upstream && git checkout master && git rebase upstream/master
git checkout -b mine
patch -Np1 -i /path/to/enable_additional_cpu_optimizations_for_gcc_v10.1+_kernel_v5.8+.patch
git commit -av
git format-patch -1
If all that is good, save me from reading up in the scenario where "upstream" changes and breaks my patchset. Now I need to manually merge: what are the steps to do it?
Disk space will not be impacted, or in a very limited way since git will use pack all common git commits between stable, torvalds, zen-kernel and so on.
Here would be what I would be doing in your context, starting from a fetch tree, this is only guidelines, there are plenty of different way to do this technicaly
# Init empty repo
$ git init linux.git && cd linux.git/
# Add all tracked repo
$ git remote add torvalds https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ git remote add archlinux https://git.archlinux.org/linux.git
$ git remote add stable https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
# Fetch all repo, have a cuppa tea
$ git fetch --all
# Create local master branches
$ git branch torvalds/master torvalds/master
$ git branch archlinux/master archlinux/master
$ git branch stable/master stable/master
# Apply your patch to local branch
$ git checkout torvalds/master
$ git apply enable_additional_cpu_optimizations_for_gcc_v10..
$ git add -A .
$ git commit -v 'build: enable additional ...'
# Create git am patch
$ git format-patch torvalds/master
# Repeat to other branches
# When we release from upstream are available
$ git checkout torvalds/master
$ git pull --rebase (or pull --ff-only)
$ git format-patch torvalds/master
OK I did what I described above. Is 98c0a7f what you're asking for?
git remote add upstream https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch upstream && git checkout master && git rebase upstream/master git checkout -b mine patch -Np1 -i /path/to/enable_additional_cpu_optimizations_for_gcc_v10.1+_kernel_v5.8+.patch git commit -av git format-patch -1
If all that is good, save me from reading up in the scenario where "upstream" changes and breaks my patchset. Now I need to manually merge: what are the steps to do it?
This does looks good indeed. if upstream break your changes, git am will interrupt the merge and will tell you exactly which file is now broken and will ask you to manually resolve the merge failure. Once you manually resolve them, you simply need to git add <file manually fixed>
and then resume the merge with git merge --continue
. (git status
will tell you what is right next step regardless)
OK thanks for the replies. I've done it a few times before and can figure my way through it.
Hi,
Did you ever consider providing patches available in this repository as patches one could
git am
rather thangit apply
? Relying ongit am
would allow to inject the patch more easily as part of a git patch management such as the one used by greg and other stable kernel patch queues, but also to keep git author and commit date.This would imply on your end to create a proper git commit and create the patch using git format-patch which should not be too far from your current process.
Thanks,