4 ms·

It's not like we (I am a Googler) email patch files around. Everything is integrated into the system. You create a CL (change list), it automatically gets a num

by skj 8y ago

It's not like we (I am a Googler) email patch files around. Everything is integrated into the system. You create a CL (change list), it automatically gets a number. People can review it, test it, or fork it (make a new CL using your CL as a starting point) as much as they want, all from that CL number.

fouronnes3 8y ago
So basically it's a branch?
- mic47 8y ago
  No, it's more like a patch. In branch, you drag with you all the dependent changes, while with patch, you have only the actual change, and information which CL -- or PR in github terms -- is dependent. With branches, if someone updates the branch you depend on, your work is based on stale stuff, and it can get ugly. Just try to do it on github :-)
- skj 8y ago
  It's missing a lot of what people expect in git branching, like history within the branch and arbitrary digraphs for forking and merging. If every branch was always merged back into head before doing anything else, and always had its commits flattened into one, and someone forking off of your branch was basically opening it up, copying the changes in your clipboard, and pasting it into a new branch with no attribution or history, then sure.
- izacus 8y ago
  Think of a CL like a Pull Request that has (and can only have) a single commit. It's visible in code review UI, has a description, has tests run on it, it can be merged by other people and it can be referenced from anywhere. Eventually it's merged into the head or dropped.
  - idontpost 8y ago
    So this is identical to squashing and rebasing your feature branch?
    - xyzzyz 8y ago
      Technically yes, but people don’t use it and think about it this way. Changelists are supposed to be small, couple hundreds of line changes at most. You don’t develop a complete feature of thousands of lines in a single CL, that would be insanely hard to review. What happens is that work gets split into small chunks, and each one is submitted separately, not to feature branch, but straight to head.
      - idontpost 8y ago
        This sounds identical to our workflow with git for all practical purposes. 1) New story gets a branch. 2) Branch gets squashed and rebased on most recent master before PR. PRs are generally under 1,000 lines changed. 3) PR is merged to master after code review.
jbf1001 8y ago
Functionally, this may be different but I am struggling to see how conceptually this makes any difference in the development process.
mcguire 8y ago
What makes this different from a branch?

by skj 8y ago

fouronnes3 8y ago

So basically it's a branch?

mic47 8y ago
No, it's more like a patch. In branch, you drag with you all the dependent changes, while with patch, you have only the actual change, and information which CL -- or PR in github terms -- is dependent. With branches, if someone updates the branch you depend on, your work is based on stale stuff, and it can get ugly. Just try to do it on github :-)
skj 8y ago
It's missing a lot of what people expect in git branching, like history within the branch and arbitrary digraphs for forking and merging. If every branch was always merged back into head before doing anything else, and always had its commits flattened into one, and someone forking off of your branch was basically opening it up, copying the changes in your clipboard, and pasting it into a new branch with no attribution or history, then sure.
izacus 8y ago
Think of a CL like a Pull Request that has (and can only have) a single commit. It's visible in code review UI, has a description, has tests run on it, it can be merged by other people and it can be referenced from anywhere. Eventually it's merged into the head or dropped.
- idontpost 8y ago
  So this is identical to squashing and rebasing your feature branch?
  - xyzzyz 8y ago
    Technically yes, but people don’t use it and think about it this way. Changelists are supposed to be small, couple hundreds of line changes at most. You don’t develop a complete feature of thousands of lines in a single CL, that would be insanely hard to review. What happens is that work gets split into small chunks, and each one is submitted separately, not to feature branch, but straight to head.
    - idontpost 8y ago
      This sounds identical to our workflow with git for all practical purposes. 1) New story gets a branch. 2) Branch gets squashed and rebased on most recent master before PR. PRs are generally under 1,000 lines changed. 3) PR is merged to master after code review.

jbf1001 8y ago

Functionally, this may be different but I am struggling to see how conceptually this makes any difference in the development process.

mcguire 8y ago

What makes this different from a branch?