4 ms·
I completely agree. The Linux kernel workflow is the only way to use git effectively and the history is always useful and each commit is nice and self-contained
by cyphar 10y ago
I completely agree. The Linux kernel workflow is the only way to use git effectively and the history is always useful and each commit is nice and self-contained. Some people apparently don't understand that "no squashing of patchsets" means that the merger shouldn't squash a patchset (not that the developer can't make the patchset clean) and that "no rewriting history" refers to master once things have been merged into it.
- seanp2k2 10y agoIs there some ~concise guidelines or post about how the Linux kernel developers use git?
- liveoneggs 10y agoread these three man pages for the original "pull request": https://git-scm.com/docs/git-format-patch https://git-scm.com/docs/git-format-patch https://git-scm.com/docs/git-send-email https://git-scm.com/docs/git-send-email https://git-scm.com/docs/git-am https://git-scm.com/docs/git-am
- juped 10y agoIt's not the only way to use git effectively, but it's definitely the canonical one. I think a Chesterton's fence rule should apply to git: if you're doing something different from LKML, you should be able to clearly explain exactly why. No linking to some blog post you found, either, unless it's by Junio Hamano (and you still have to explain, you can't just link).