5 ms·

One of his points is that you should only pull rarely: And, in fact, preferably you don't pull my tree at ALL, since nothing in my tree should be releva

by morsch 13y ago

One of his points is that you should only pull rarely: And, in fact, preferably you don't pull my tree at ALL, since nothing in my tree should be relevant to the development work _you_ do. Sometimes you have to (in order to solve some particularly nasty dependency issue), but it should be a very rare and special thing, and you should think very hard about it. That might work well for the kind of highly decoupled development he's dealing with, but I'm not sure it'll work for the kind of work I do with my colleagues. The first thing I do every morning is a git pull (often surrounded by git stash [pop] and sometimes with a --rebase appended if I have outgoing commits), because I might need the stuff a colleague worked on the past days, or we might work in the same files and generate lots of conflicts otherwise. Maybe I'm doing it wrong.

crististm 13y ago
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.
- IgorPartola 13y ago
  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.
  - dan00 13y ago
    > 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.
    - IgorPartola 13y ago
      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.
  - dkarl 13y ago
    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.
  - saraid216 13y ago
    > 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.
- Peaker 13y ago
  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.
alexchamberlain 13y ago
Do you work on topic branches?
- morsch 13y ago
  Sometimes -- I usually don't pull into those unless strictly necessary.
- alexchamberlain 13y ago
  I highly recommend a bout where you do everything on topic branches; the advantages will become sell evident over time and then you will know when and when not to use them.
dan00 13y ago
I don't think, that you're doing something particularly wrong, but for a big project like linux you have to keep the changes as isolated as possible, otherwise it will be quite hard to identify the causes, if there're problems. So it's better to base your changes on the commit of a linux release, which has been tested quite a lot, which has some kind of defined state.
glanotte 13y ago
I don't think the point is that you should pull rarely. I think the key there is _my_ tree and he later refers to a branch named linus. I would suspect that he maintains his own development tree that gets pushed to the central repository and then merged to master when he feels it is ready. But prior to it getting merged, it is random and subject to his own rebasing. I have a similar flow, I might maintain multiple feature branches but I will pull and rebase master very regularly to be sure I am working against the most recent code base. I will also rebase my work to squash commits to create a clean history prior to moving work from my feature branches to master. So if someone was to pull in one of my feature branches prior to it being merged or tagged, that tree would very likely change and then we have two versions of my work that would create a merge nightmare when we decided to get everything into master.
jlarocco 13y ago
I don't think he's talking about "git pull" from a central repo, but instead a "git pull <url-to-linus'-private-repo>". But I can also imagine it being useful for everybody to pull the code from the last release and work on it, before a single person pulls the code, merges, and commits it to the central repo.
- dadoes 13y ago
  Yeah, I think you're right. Linus isn't talking about pulling in general, just pulling from his work.

by morsch 13y ago

crististm 13y ago

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.

IgorPartola 13y ago
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.
- dan00 13y ago
  > 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.
  - IgorPartola 13y ago
    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.
- dkarl 13y ago
  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.
- saraid216 13y ago
  > 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.
Peaker 13y ago
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.

alexchamberlain 13y ago

Do you work on topic branches?

morsch 13y ago
Sometimes -- I usually don't pull into those unless strictly necessary.
alexchamberlain 13y ago
I highly recommend a bout where you do everything on topic branches; the advantages will become sell evident over time and then you will know when and when not to use them.

dan00 13y ago

I don't think, that you're doing something particularly wrong, but for a big project like linux you have to keep the changes as isolated as possible, otherwise it will be quite hard to identify the causes, if there're problems. So it's better to base your changes on the commit of a linux release, which has been tested quite a lot, which has some kind of defined state.

glanotte 13y ago

I don't think the point is that you should pull rarely. I think the key there is _my_ tree and he later refers to a branch named linus. I would suspect that he maintains his own development tree that gets pushed to the central repository and then merged to master when he feels it is ready. But prior to it getting merged, it is random and subject to his own rebasing. I have a similar flow, I might maintain multiple feature branches but I will pull and rebase master very regularly to be sure I am working against the most recent code base. I will also rebase my work to squash commits to create a clean history prior to moving work from my feature branches to master. So if someone was to pull in one of my feature branches prior to it being merged or tagged, that tree would very likely change and then we have two versions of my work that would create a merge nightmare when we decided to get everything into master.

jlarocco 13y ago

I don't think he's talking about "git pull" from a central repo, but instead a "git pull <url-to-linus'-private-repo>". But I can also imagine it being useful for everybody to pull the code from the last release and work on it, before a single person pulls the code, merges, and commits it to the central repo.

dadoes 13y ago
Yeah, I think you're right. Linus isn't talking about pulling in general, just pulling from his work.