An alternative that worked really well for me is "do not push broken code". Linus is saying "If you pull at a random time, you might get cruft in your local tree". Why is that? There should be no cruft upstream from you. There may be a conflict between your code and remote, but that is up to you to resolve as the remote works and your code does not work with it.
His suggestion that in order to keep your git history pristine you should just email patches until you can get to a working state seems bizarre. git is a tool that works really well for collaborating on something until it works. In a small project, who gives a crap if you see a commit that fixes the previous commit once in a blue moon. Yes, on a large project like the Linux kernel that might get annoying, but for 99% of people it's irrelevant.
I think his comment is relevant for people who treat their "private" git history very differently from the "public" git history. My "private" git history contains lots of minor commits for stuff like checkpointing, fixing stupid errors, etc. The commit messages sometimes aren't very informative. I clean things up when I reach a good working state, and the history that becomes public is much simpler, with fewer commits and an informative message on each commit. If I share my crappy "private" history with someone else, then I forfeit my ability to clean it up later. That doesn't matter if you keep a pretty clean history in the first place, but I definitely do not.
> An alternative that worked really well for me is "do not push broken code". Linus is saying "If you pull at a random time, you might get cruft in your local tree". Why is that?
It's not about pushing broken code, it's about having a very complex code
base and you just can't foresee how each change will behave before it has
been tested by a lot of people on a lot of different machines.
A linux release is a pretty good point in time to get a quite well tested
version and therefore it's a good base for your changes and to be able
to test how your changes - only your changes - behave.
Good point. However, that still means that this advice does not apply to most people in the wild as most people are not working on projects that large.
> His suggestion that in order to keep your git history pristine you should just email patches until you can get to a working state seems bizarre.
To me, it doesn't sound meaningfully different from walking over to a coworker and arguing over the code or its results for a while. The "emailing patches" thing seems more like a slow-by-necessity feedback loop due to the fact that Linux contributors are across the world and even IMing or real-time screen-sharing doesn't make sense.
The distributed nature of the Linux kernel is exactly where imposing some structure on how patches are distributed would make sense to me. Linus resisted doing anything but deal with emailed patches for a really long time until he was called out on it. His reasoning was that he can keep up with it and keep everything straight, and the argument against him was that others couldn't.
I know that keeping a clean history is very important, but keeping all the patches straight IMHO is even more important and git is exactly the tool for that job. Email is the wrong tool for that job aside from some very occasional "check this out, am I being stupid here?" type things.
Then again, I am not a kernel developer and have no idea what I am talking about. All I can contribute is that on small-ish projects (up to 10 people on a team), using git differently makes everyone's lives easier at the cost of the history looking slightly worse.
His suggestion that in order to keep your git history pristine you should just email patches until you can get to a working state seems bizarre. git is a tool that works really well for collaborating on something until it works. In a small project, who gives a crap if you see a commit that fixes the previous commit once in a blue moon. Yes, on a large project like the Linux kernel that might get annoying, but for 99% of people it's irrelevant.