4 ms·

I'm assuming this is a response to GitLab's concept of a WIP merge request.

shaki-dora 8y ago
Well, I guess there’s nothing wrong with Github replicating good ideas, considering Gitlab is pretty close to an identical clone.
- techntoke 8y ago
  Except GitLab has an open-source self-hosted option and an entire DevOps pipeline with Kubernetes integration and many more features features than GitHub. They also provided free private repos long before GitHub.
  - dvtrn 8y ago
    So what you're saying is people have options for their VCS? Great! :)
    - techntoke 8y ago
      No, I'm suggesting GitLab is not close to an identical clone. It is much better with many many more features and reviewable source code.
- markovbot 8y ago
  Nope, didn't mean to imply there was! GitLab certainly seems to have replicated a lot of the good ideas from GitHub, I just wanted to point out that it now seems to be going the other direction as well.
dkhenry 8y ago
I don't know if I would call it GitLab's concept. Every place I have worked at that has used github has had the idea of a Work In Progress pull request. Its a pretty natural concept for an multi-member development team. So much so that all of the places I have used it have written explicit CI checks that would check for a label on the PR or the title to be in a given format and would fail to make sure you couldn't merge the branch until WIP was removed.
- raphlinus 8y ago
  Gerrit has had the concept of "draft" for a long time. It's also better at multiple "patchsets" as a "changelist" evolves, some of which can have rebasing without needing a forced update. On the other hand, it's somewhat hacky the way it layers on top of git, requiring a "change id" to link the different patchsets together. Much of the way it works came from trying to deliver a similar experience as Perforce. Disclosure: worked at Google, have used both systems a lot.
  - hipnoizz 8y ago
    I found a small inconvenience of maintaining ChangeId (usually handled automatically by the git hook) a very small price to pay for all great features provided by Gerrit. I know that Gerrit team investigated few times a better way to attach this metadata to commits but so far it works this way. What other 'hacky ways' you mean? 'Magic' refs/for/* branches can be a bit weird at beginning. On the other hand introducing Gerrit 7-8 years ago to my back-then employer made me understand the Git model much better. Anyway, e.g. IntelliJ IDEA plugin for Gerrit should alleviate almost all pain points (if someone stick to JetBrains products). Were you working on Android/AOSP? I always assumed that this is the primary project where Googlers have a chance to work with Gerrit. I thought that Google uses some in-house CR system, as mentioned by https://www.gerritcodereview.com/about.html https://www.gerritcodereview.com/about.html.
    - raphlinus 8y ago
      Yes, Android then Fuchsia. I agree it's good, overall I prefer it to Github, but by "hacky" I mostly mean it's very much out of step from the way the rest of the ecosystem works. This is much more true for repo / jiri (which is Google's own spin on the submodule problem), but includes change ids.
- deleted 8y ago
  [deleted]
mikece 8y ago
I doubt it. I've heard interviewees for years on podcasts talk about opening a PR as a means to discussing something long before the code is actually ready. Seems like this is just a feature following a common though informal common practice.

Well, I guess there’s nothing wrong with Github replicating good ideas, considering Gitlab is pretty close to an identical clone.

techntoke 8y ago
Except GitLab has an open-source self-hosted option and an entire DevOps pipeline with Kubernetes integration and many more features features than GitHub. They also provided free private repos long before GitHub.
- dvtrn 8y ago
  So what you're saying is people have options for their VCS? Great! :)
  - techntoke 8y ago
    No, I'm suggesting GitLab is not close to an identical clone. It is much better with many many more features and reviewable source code.
markovbot 8y ago
Nope, didn't mean to imply there was! GitLab certainly seems to have replicated a lot of the good ideas from GitHub, I just wanted to point out that it now seems to be going the other direction as well.

dkhenry 8y ago

I don't know if I would call it GitLab's concept. Every place I have worked at that has used github has had the idea of a Work In Progress pull request. Its a pretty natural concept for an multi-member development team. So much so that all of the places I have used it have written explicit CI checks that would check for a label on the PR or the title to be in a given format and would fail to make sure you couldn't merge the branch until WIP was removed.

raphlinus 8y ago
Gerrit has had the concept of "draft" for a long time. It's also better at multiple "patchsets" as a "changelist" evolves, some of which can have rebasing without needing a forced update. On the other hand, it's somewhat hacky the way it layers on top of git, requiring a "change id" to link the different patchsets together. Much of the way it works came from trying to deliver a similar experience as Perforce. Disclosure: worked at Google, have used both systems a lot.
- hipnoizz 8y ago
  I found a small inconvenience of maintaining ChangeId (usually handled automatically by the git hook) a very small price to pay for all great features provided by Gerrit. I know that Gerrit team investigated few times a better way to attach this metadata to commits but so far it works this way. What other 'hacky ways' you mean? 'Magic' refs/for/* branches can be a bit weird at beginning. On the other hand introducing Gerrit 7-8 years ago to my back-then employer made me understand the Git model much better. Anyway, e.g. IntelliJ IDEA plugin for Gerrit should alleviate almost all pain points (if someone stick to JetBrains products). Were you working on Android/AOSP? I always assumed that this is the primary project where Googlers have a chance to work with Gerrit. I thought that Google uses some in-house CR system, as mentioned by https://www.gerritcodereview.com/about.html https://www.gerritcodereview.com/about.html.
  - raphlinus 8y ago
    Yes, Android then Fuchsia. I agree it's good, overall I prefer it to Github, but by "hacky" I mostly mean it's very much out of step from the way the rest of the ecosystem works. This is much more true for repo / jiri (which is Google's own spin on the submodule problem), but includes change ids.
deleted 8y ago
[deleted]

mikece 8y ago

I doubt it. I've heard interviewees for years on podcasts talk about opening a PR as a means to discussing something long before the code is actually ready. Seems like this is just a feature following a common though informal common practice.