Linus comments is valid in your case: your colleague's work is relevant to you, thus you have a reason to pull. Otherwise, pulling on a time base will give you little benefit besides the occasional breaking of your stuff.
If you review now Linus comment, it makes sense that pulling should be done on a feature branch: one that has a complete, working solution of something you need.
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.
Continuous integration, or frequently pulling, has huge advantages:
* Breakage is localized to small merges. Instead of debugging the breakage of 1 month of work integrated with yours, you debug it a day of work at a time. Localized/differential debugging is much easier.
* Ditto with conflicts. Dealing with daily conflicts is much easier than dealing with the aggregate of a month's conflict. Beyond a certain threshold of difficulty, conflict resolution quality becomes very low. People just give up and start resolving conflicts semi-randomly.
If you review now Linus comment, it makes sense that pulling should be done on a feature branch: one that has a complete, working solution of something you need.