5 ms·

I find it mildly amusing what you're calling "traditional git workflows". It seems pretty clear to me that the traditional git workflow is the one used by the

I find it mildly amusing what you're calling "traditional git workflows". It seems pretty clear to me that the traditional git workflow is the one used by the Linux kernel, which is after all the reason why git exists in the first place. The traditional git workflow strikes the correct balance between locally rebasing to create a logical sequence of meaningful commits without squashing everything when your work gets published and merged. A lot of the noise on the git-related threads here on HN would probably be avoided or at least reduced if everybody was actually aware how the traditional git workflow f- i.e. the Linux kernel workflow - works.

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 ago
  Is there some ~concise guidelines or post about how the Linux kernel developers use git?
  - liveoneggs 10y ago
    read 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 ago
  It'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).

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 ago
Is there some ~concise guidelines or post about how the Linux kernel developers use git?
- liveoneggs 10y ago
  read 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 ago
It'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).