4 ms·

You don't necessarily go to github just to use git, but for the community, advertisement, ... Also facebook is a big company, and like all bigger companies man

by chme 9y ago

You don't necessarily go to github just to use git, but for the community, advertisement, ... Also facebook is a big company, and like all bigger companies many people in it prefer different stuff.

yeukhon 9y ago
I am not sure if I wasn't clear. I have never worked for FB, so I don't know how internally FB handles this. But my understanding is, FB uses Hg for its main repository. However, FB has developed open source projects which most of them are published on Github, so for those development teams they work with Git. The question is, how do they reconcile some dev teams are context switching between hg and git? How common is that? Personally, I would allow one DVCS only, so my internal development platform doesn't have to support both Git and Hg (who knows, maybe FB also have teams using SVN for good reasons).
- chme 9y ago
  I don't work at facebook. But there is stuff like this: https://hg-git.github.io/ https://hg-git.github.io/ So in the end it doesn't really matter.
- nerpderp83 9y ago
  Any large code hosting company will allow multiple client protocols for checkin checkout. You can even use SVN to do github checkouts https://help.github.com/articles/support-for-subversion-clients/ https://help.github.com/articles/support-for-subversion-clie...
- spicyj 9y ago
  People at Facebook who use both internal repos and external ones (like me) need to know both hg and git. It's not too hard; the two provide similar functionality and many of our hg extensions (https://bitbucket.org/facebook/hg-experimental https://bitbucket.org/facebook/hg-experimental) make hg more git-like in some ways. Most of our open source projects also use an in-house tool "fbshipit" https://github.com/facebook/fbshipit https://github.com/facebook/fbshipit to automatically export internal commits to open source so if you make changes that happen to touch an open source project but it's not your primary focus then you can work entirely in the internal (hg) repo and your changes get copied out automatically.
  - Cogito 9y ago
    Do you go through a process to clean those commits for open source? It sounds really interesting - I assume the tool is mostly just for marshalling commits (or parts of commits?) that touch external projects, but I would also assume that someone then needs to do the work to get those changes into a publishable state. Organising commits into a consistent set of changes, meaningful commit messages for the target project, removing any vestiges of internal content. Is there a team who manage all of those aspects, or is it down to the individual developers liaising with the open source projects?
    - spicyj 9y ago
      We don't. We err on the side of moving faster here and asking people not to put internal-only info in commit messages that might be exported. We don't reorganize commits since it's usually more valuable to export them as they were developed/committed internally. No one looks at every commit before they get published to our GitHub repos though, other than the regular code review that happens on every internal commit.
      - Cogito 9y ago
        Makes a lot of sense. What happens in the case of a series of commits that belong together? Is there a way of making sure they are applied to the project correctly (say in a branch or something)? I guess the point is moot if internally you are more-or-less working on the full tree of the external project. In that case, the commits would already be organised however they needed to be. The alternative would be that the external project is mixed in with an internal one, and you make commits against both in the same tree. Lots of potential edge cases around refactored commits etc, and I would guess the tool assumes you follow a certain set of workflow guidelines (like not force pushing a new set of commits) so those edge cases may not be that important.
        spicyj 9y ago
        External projects that use fbshipit each live in a subdirectory of an internal project. We don't use branches or merge commits, and commits are exported in order.
- ahupp 9y ago
  I'm at FB and switch between the two pretty regularly. Of course I'd prefer to just use one, but I haven't found this is a problem in practice.

by chme 9y ago

You don't necessarily go to github just to use git, but for the community, advertisement, ... Also facebook is a big company, and like all bigger companies many people in it prefer different stuff.

yeukhon 9y ago

I am not sure if I wasn't clear. I have never worked for FB, so I don't know how internally FB handles this. But my understanding is, FB uses Hg for its main repository. However, FB has developed open source projects which most of them are published on Github, so for those development teams they work with Git. The question is, how do they reconcile some dev teams are context switching between hg and git? How common is that? Personally, I would allow one DVCS only, so my internal development platform doesn't have to support both Git and Hg (who knows, maybe FB also have teams using SVN for good reasons).

chme 9y ago
I don't work at facebook. But there is stuff like this: https://hg-git.github.io/ https://hg-git.github.io/ So in the end it doesn't really matter.
nerpderp83 9y ago
Any large code hosting company will allow multiple client protocols for checkin checkout. You can even use SVN to do github checkouts https://help.github.com/articles/support-for-subversion-clients/ https://help.github.com/articles/support-for-subversion-clie...
spicyj 9y ago
People at Facebook who use both internal repos and external ones (like me) need to know both hg and git. It's not too hard; the two provide similar functionality and many of our hg extensions (https://bitbucket.org/facebook/hg-experimental https://bitbucket.org/facebook/hg-experimental) make hg more git-like in some ways. Most of our open source projects also use an in-house tool "fbshipit" https://github.com/facebook/fbshipit https://github.com/facebook/fbshipit to automatically export internal commits to open source so if you make changes that happen to touch an open source project but it's not your primary focus then you can work entirely in the internal (hg) repo and your changes get copied out automatically.
- Cogito 9y ago
  Do you go through a process to clean those commits for open source? It sounds really interesting - I assume the tool is mostly just for marshalling commits (or parts of commits?) that touch external projects, but I would also assume that someone then needs to do the work to get those changes into a publishable state. Organising commits into a consistent set of changes, meaningful commit messages for the target project, removing any vestiges of internal content. Is there a team who manage all of those aspects, or is it down to the individual developers liaising with the open source projects?
  - spicyj 9y ago
    We don't. We err on the side of moving faster here and asking people not to put internal-only info in commit messages that might be exported. We don't reorganize commits since it's usually more valuable to export them as they were developed/committed internally. No one looks at every commit before they get published to our GitHub repos though, other than the regular code review that happens on every internal commit.
    - Cogito 9y ago
      Makes a lot of sense. What happens in the case of a series of commits that belong together? Is there a way of making sure they are applied to the project correctly (say in a branch or something)? I guess the point is moot if internally you are more-or-less working on the full tree of the external project. In that case, the commits would already be organised however they needed to be. The alternative would be that the external project is mixed in with an internal one, and you make commits against both in the same tree. Lots of potential edge cases around refactored commits etc, and I would guess the tool assumes you follow a certain set of workflow guidelines (like not force pushing a new set of commits) so those edge cases may not be that important.
      - spicyj 9y ago
        External projects that use fbshipit each live in a subdirectory of an internal project. We don't use branches or merge commits, and commits are exported in order.
ahupp 9y ago
I'm at FB and switch between the two pretty regularly. Of course I'd prefer to just use one, but I haven't found this is a problem in practice.