Hi,
some of you may remember that we initially had a git
development pattern that simply piles up patches
in a single letux-kernel branch.
This is a good approach in some cases:
* easy to understand
* multiple contributors possible
* it is clear what the latest version is
* never rebase
* no git push --force and git pull --force needed
But it has a big drawback:
* features are not packed into easily identifiable "development branches"
* it is not possible to git format-patch for upstreaming a single feature
* it is not possible to rebase on top of linus/master or linux-next
* it is not possible to work with feedback by upstream reviewers
The reason is that Linux has a different, non-linear development
model:
* there is linus/master
* new features (e.g. device drivers, fixes, defconfig, device tree) are always on top of linus/master or linux-next
* there is one patch set per feature change
* clean patches (they even discuss commas in commit messages)
* rebase often
So at some point of Letux-kernel development we did switch to
the Linux development model.
Well, not completely. We already had piled up ca. 3-4 years
of GTA04 development using the linear model.
So we introduced our own letux-base branch. This is the base
for all current feature development.
And every Monday or so, I merged the latest linus/master into
letux-base and rebased all relevant feature branches.
This worked quite well for all the stuff we have developed for
e.g. the Pyra or the GTA04A5 to name two of them.
And some of these feature branches could easily be rebased to
either letux-base, linus/master or linux-next to submit patches
upstream.
But we still had a lot of legacy commits in letux-base which
made it impossible to rebase letux-base itself.
Now it would have been too easy if git would provide a simple
git cherry-pick linus/master letux-base -- interesting-files
Such a command does not exist :(
Therefore I wrote and debugged in the past weeks a script
that:
a) reads a control file (which says which source files should go
into which new feature branch)
b) does a git blame to find out when these files have been changed
c) works with git diff, git am and git commit -C to replay the
filtered changes into a new feature-branch that is on top of the
latest linus-master
There were some difficult aspects to solve: how to handle new
files and removed files and renames. How to handle permission
changes or permissions for new files (some scripts have +x mode).
And how to keep original Author and Author date so that proper
attribution can be maintained.
After a lot of debugging it now works and the letux git has been
reworked.
The result is a set of work/letux-base branches that exactly
copy the current letux-base if merged on top of v4.14-rc3.
All needs some more review, but I think we can soon switch
Letux-kernel completely to the official Linux git process.
Then we can review and reduce the new work/letux-base patch
sets since there are some spurious additions and removals
which have no function. They come from this effect:
/--- A ---------- C ---------\
/ \
common-base E ------ head
\ /
\---------- B --------- D ---/
If A adds some feature and we try to make a sequence of
common-base - A - B - C - D - E --- head
out of it, the algorithm will add the feature in A, remove it
in B, add in C, remove in D and finally add in E.
And in some cases almost all additions by A and B have
been removed by C and D so that a single line of change
may remain from 10 commits.
This needs manual work to squeeze all these patches into a
single one, but is not very difficult or urgent to do now.
The result of such a cleanup will not change anything in
our letux tree, but make it more obvious which patches we
have inherited from ancient time. And it makes it easier
to check if they are still good or hidden time bombs...
So please look at the latest git.
For reference, let me try to write branches as formulae:
old:
letux-base := letux-base + v4.14-rc1
rebase([all feature branches], letux-base)
letux-4.14-rc1 := letux-base + [all feature branches]
new (two stages):
letux-base := v4.14-rc3
rebase([all letux-base branches], letux-base)
letux-intermediate = letux-base + [all letux-base branches]
rebase([all feature branches], letux-intermediate)
letux-4.14-rc3 := letux-intermediate + [all feature branches|
So everything which makes up letux is placed on top of v4.14-rc3
instead of letux-base where v4.14-rc3 was merged in.
Anyways, development of letux-kernel continues almost unchanged.
Just in a slightly different set of branches.
BR,
Nikolaus