3 ms·
> I think it is quite telling that the Linux kernel developers themselves prefer a simple, linear history in the end What do you mean? This is what the current
by drothlis 11y ago
> I think it is quite telling that the Linux kernel developers themselves prefer a simple, linear history in the end
What do you mean? This is what the current git history of the linux kernel looks like:
* 12b9fa6 Merge branch 'for-linus' of git://git.kernel.org/pu
|\
| * 5129fa4 do_last(): ELOOP failure exit should be done after
| * a7f7754 should_follow_link(): validate ->d_seq after having
| * d456564 namei: ->d_inode of a pinned dentry is stable only
| * c80567c do_last(): don't let a bogus return value from ->op
| * 0fcbf99 fs: return -EOPNOTSUPP if clone is not supported
| * b6853f7 hpfs: don't truncate the file when delete fails
* | 340b3a5 Merge tag 'armsoc-fixes' of git://git.kernel.org/
|\ \
| * \ d877a21 Merge tag 'renesas-soc-fixes-for-v4.5' of git:/
| |\ \
| | * | 901c5ff ARM: shmobile: Remove shmobile_boot_arg
| | * | 4e960f5 ARM: shmobile: Move shmobile_smp_{mpidr, fn, ar
| | * | b1568d8 ARM: shmobile: r8a7779: Remove remainings of re
| | * | d2613f5 ARM: shmobile: Move shmobile_scu_base from .tex
| * | | 7931845 MAINTAINERS: Extend info, add wiki and ml for m
| * | | 9fa6c2b Merge tag 'omap-for-v4.5/fixes-rc5' of git://
| |\ \ \
| | * | | 3f315c5 ARM: OMAP2+: Fix onenand initialization to av
| | * | | e327b3f Revert "regulator: tps65217: remove tps65217.
| * | | | a9e5547 MAINTAINERS: alpine: add a new maintainer and
| * | | | 5e45a25 ARM: at91/dt: fix typo in sama5d2 pinmux desc
| * | | | b223c9f Merge tag 'imx-fixes-4.5' of git://git.kern
| |\ \ \ \
| | * | | | f5d0ca2 ARM: dts: imx6: remove bogus interrupt-pare
| | | |/ /
| | |/| |
| * | | | e3acd74 Merge tag 'omap-for-v4.5/fixes-rc3-v2' of g
| |\ \ \ \
| | | |/ /
| | |/| |
| | * | | cf26f11 ARM: OMAP2+: Fix omap_device for module reloa
| | * | | 08c78e9 ARM: OMAP2+: Improve omap_device error for dr
| | * | | bf26927 ARM: DTS: am57xx-beagle-x15: Select SYS_CLK2
| | * | | a5b8751 ARM: dts: am335x/am57xx: replace gpio-key,wak
| | * | | 5f35dc4 ARM: OMAP2+: Set system_rev from ATAGS for n9
| * | | | 74a46ec Merge tag 'mvebu-fixes-4.5-2' of git://git.
| |\ \ \ \
| | * | | | 44361a2 ARM: dts: orion5x: fix the missing mtd flas
| | * | | | 9d021c9 ARM: dts: kirkwood: use unique machine name
* | | | | | 691429e Merge branch 'akpm' (patches from Andrew)
|\ \ \ \ \ \
| * | | | | | 7f6d5b5 dax: move writeback calls into the filesy
Merge commits galore.
- ajdlinux 11y agoIt's true that at the top level, most of Linus' commits are merge commits. However, on a per-subsystem level, we very much favour a nice linear history. In most parts of the kernel, it's rare to go beyond 2 levels of merging, which given that the kernel has something like 1500+ developers and well over 10k+ commits per release cycle, is fairly linear...
- drothlis 11y agoInteresting (I'm not a kernel developer). What's the workflow at the subsystem level -- does the maintainer do a `git fetch` followed by `git rebase`? Or is the rebasing done via email patches and `git am`?
- ajdlinux 11y agoIt's pretty much all done by emailed patches with git am - I maintain a personal tree on GitHub and one privately in my company, but they're purely for experimentation, not for sending pull requests. Email is how we submit code, discuss code and review code. You use git send-email to fire your patches off to the appropriate maintainer + mailing list, you make your modifications/rebase it/etc then send off V2, V3, ... V14 of your patch until everyone's happy. Among other things, we tend to be quite picky about getting commit messages right, and making sure that patch series are "structured" in a "nice" way - so git rebase -i is one of the most common commands I run on my private branches... Maintainers all have their own tools and scripts to help automate and track the whole process - in the area where I work, we track things using Patchwork (see http://patchwork.ozlabs.org/project/linuxppc-dev/list/ http://patchwork.ozlabs.org/project/linuxppc-dev/list/). When the maintainer's happy with a patch, it gets applied and pushed to one of the trees they use (e.g. with powerpc, we have powerpc-next for feature development and powerpc-fixes for important fixes). Eventually, they send Linus a pull request, and it makes its way into the kernel mainline. It's a bit of a tricky system that requires understanding of the kernel community's social norms to get right - which I'm not entirely happy with but I don't think it'll change particularly quickly. However, it's also surprisingly effective - the kernel is one of the largest and most distributed individual projects in the open source world, and as a community we keep pushing out releases.