5 ms·

So you can prepare a change for trunk, and share the change with your colleagues to collaborate on. Don't see why branching should be needed for this.

by hknd 8y ago

weinzierl 8y ago
That's what I meant in my question with "share code by other means". It works but in my opinion it is a large pain and I can't believe people at Google work by sending patches back and forth.
- hknd 8y ago
  It's actually really easy to create a "patch", so people usually create small "patches" and send them to people if they need any feedback on those. A "patch" is actually just a commit (actually a changelist) which can be viewed, commented and edited in the browser based code review and IDE tool. Imho I find it much easier to get an url of a "patch" and comment on it inline, instead of having to checkout a branch etc. If you have a question to a specific example I'm happy to answer it in the way it would've been done within Google/Facebook.
  - weinzierl 8y ago
    Thank you, I appreciate your effort to help me understand this better and our exchange helped me to make progress. One thing I infer from your answer is that it seems that there is an established process and dedicated tooling for working with patches at Google. I think a lot of my pain with patches stems more from the lack of process and lack of an agreement on formats and standards in my environment than from the use of patches per se. Where I still see an advantage of branches is that they facilitate documentation of what has been done by whom and when. All of this documentation is in the same place and form as the documentation of changes in the trunk. It all is in commit messages whereas patches are only documented somewhere else, possibly in the Email or IM used to send the patch. Even if most of the branch documentation does not survive on trunk when we squash the final merge it is still there and easy to find as long as the branch doesn't get deleted. When I want to look up why I applied a certain patch I'll have to dig through my messages. I think that makes it harder to work with patches than with branches.
    - hknd 8y ago
      A "patch" in Google/Facebook/Twitter is the same as a commit. It has a (mostly) descriptive commit message, references to bug tickets and might contain links to documentation, screenshots and mocks. You basically work on a "patch" (changelist), get feedback from others and send it out to review at the end. Before you can submit (commit) it, you'll have to sync to "head" (to have the latest changes) and run all tests. ^ most of this happens automatically, and as most changelists ("patches") are small, this happens very fast and async in the background.
    - ranma42 8y ago
      FWIW coreboot is an open-source project that uses a similar style, where you need to upload your change to the review tool (https://review.coreboot.org/ https://review.coreboot.org/, which is using gerrit https://www.gerritcodereview.com/ https://www.gerritcodereview.com/) and people comment and LGTM in there and then it gets committed to the master branch once everything looks good.
    - brown9-2 8y ago
      I think what you are missing is that Google's SCM has different concepts and terms than Git. Google's system is derived from Perforce, which has the concept of a changelist (think: commit), which can be "pending" and stored on the server for review/cloning by other developers: https://www.perforce.com/perforce/doc.051/manuals/p4guide/07_changelists.html https://www.perforce.com/perforce/doc.051/manuals/p4guide/07... This allows you to share work without (in Git terms) pushing to master. Branches in Perforce-like systems tend to be more heavyweight and permanent (IIRC you have to branch an entire path of files, it is not the same as the Git concept of "branch" which is just a commit that points to another parent commit). You can think of the system as enabling you, in Git terms, to create pull requests without the creation of an underlying branch.
- hopler 8y ago
  Your changes aren't sitting on your machine. They are hosted on a server or in a git fork. After test and code review, you merge to head before deploying to production or other people make follow-on changes.
- 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?

So you can prepare a change for trunk, and share the change with your colleagues to collaborate on. Don't see why branching should be needed for this.

by hknd 8y ago

So you can prepare a change for trunk, and share the change with your colleagues to collaborate on. Don't see why branching should be needed for this.

weinzierl 8y ago

That's what I meant in my question with "share code by other means". It works but in my opinion it is a large pain and I can't believe people at Google work by sending patches back and forth.

hknd 8y ago
It's actually really easy to create a "patch", so people usually create small "patches" and send them to people if they need any feedback on those. A "patch" is actually just a commit (actually a changelist) which can be viewed, commented and edited in the browser based code review and IDE tool. Imho I find it much easier to get an url of a "patch" and comment on it inline, instead of having to checkout a branch etc. If you have a question to a specific example I'm happy to answer it in the way it would've been done within Google/Facebook.
- weinzierl 8y ago
  Thank you, I appreciate your effort to help me understand this better and our exchange helped me to make progress. One thing I infer from your answer is that it seems that there is an established process and dedicated tooling for working with patches at Google. I think a lot of my pain with patches stems more from the lack of process and lack of an agreement on formats and standards in my environment than from the use of patches per se. Where I still see an advantage of branches is that they facilitate documentation of what has been done by whom and when. All of this documentation is in the same place and form as the documentation of changes in the trunk. It all is in commit messages whereas patches are only documented somewhere else, possibly in the Email or IM used to send the patch. Even if most of the branch documentation does not survive on trunk when we squash the final merge it is still there and easy to find as long as the branch doesn't get deleted. When I want to look up why I applied a certain patch I'll have to dig through my messages. I think that makes it harder to work with patches than with branches.
  - hknd 8y ago
    A "patch" in Google/Facebook/Twitter is the same as a commit. It has a (mostly) descriptive commit message, references to bug tickets and might contain links to documentation, screenshots and mocks. You basically work on a "patch" (changelist), get feedback from others and send it out to review at the end. Before you can submit (commit) it, you'll have to sync to "head" (to have the latest changes) and run all tests. ^ most of this happens automatically, and as most changelists ("patches") are small, this happens very fast and async in the background.
  - ranma42 8y ago
    FWIW coreboot is an open-source project that uses a similar style, where you need to upload your change to the review tool (https://review.coreboot.org/ https://review.coreboot.org/, which is using gerrit https://www.gerritcodereview.com/ https://www.gerritcodereview.com/) and people comment and LGTM in there and then it gets committed to the master branch once everything looks good.
  - brown9-2 8y ago
    I think what you are missing is that Google's SCM has different concepts and terms than Git. Google's system is derived from Perforce, which has the concept of a changelist (think: commit), which can be "pending" and stored on the server for review/cloning by other developers: https://www.perforce.com/perforce/doc.051/manuals/p4guide/07_changelists.html https://www.perforce.com/perforce/doc.051/manuals/p4guide/07... This allows you to share work without (in Git terms) pushing to master. Branches in Perforce-like systems tend to be more heavyweight and permanent (IIRC you have to branch an entire path of files, it is not the same as the Git concept of "branch" which is just a commit that points to another parent commit). You can think of the system as enabling you, in Git terms, to create pull requests without the creation of an underlying branch.
hopler 8y ago
Your changes aren't sitting on your machine. They are hosted on a server or in a git fork. After test and code review, you merge to head before deploying to production or other people make follow-on changes.
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?