1. Bitbucket
  2. Public Issue Tracker
  3. master
  4. Issues

Issues

Issue #3288 wontfix

Remote pull requests to GitHub, etc (BB-3054)

Martin Geisler
created an issue

Hi,

It would be cool if it was possible to submit pull requests from Bitbucket to other big DVCS hosting sites. This would of course require collaboration with them.

I'm thinking of a system where GitHub can send a request to a URL at Bitbucket with information about the GitHub repository and branch to pull. Bitbucket would then present this like a normal pull request (maybe even do the pull into a temporary repository so that you can show the diff) and if the user approves the request, the pull is done.

Comments on the pull request should probably be directed back to the original site.

This was discussed here first: https://plus.google.com/108957994038017966408/posts/PaB9jVuEkwt

Comments (78)

  1. Dylan Etkin

    Hi Martin,

    We have talked about this internally as well, it would be cool.

    I will be honest, it did not jump to the top of the backlog but it is there.

    Cheers,

    Dylan

  2. Borek Bernard

    This would be really cool. Today, although I like BitBucket better than GitHub, I need to have an account and some of my repositories over at BitBucket simply to collaborate with other GitHub users. If this "wall" falls down I can happily live just here on BitBucket.

    If this needs cooperation with GitHub (like it probably does), is there already a ticket for that in their system? I would vote for that there too but can't find a link at the moment.

  3. Anonymous

    one simple solution would be that bitbucket create a key pair. we can add this to bitbucket and they can do simple git operations, no?

  4. Martin Geisler reporter

    Please stop adding +1 comments — add yourself as a watcher instead. That way you avoid sending out emails to everybody else who watches the issue and you still show your interest it.

  5. Geert Schuring

    Indeed Martin! Considering the fact that there are already 50+ watchers... maybe its time we start drawing attention to this issue a little more? Any ideas on how to do that, other than blogging and tweeting?

  6. Martin Geisler reporter

    Please just add yourself as a watcher on the issue instead of adding "+1" comments. Your "+1" comments go out to everybody who watch the issue (114 people right now).

  7. Nate Peterson

    People, please stop adding "+1" comments! It doesn't do anyone any good, and just annoys all current 127 watchers. If you want to show your support of this feature, please add yourself as a watcher at the top of the page!

  8. frnhr

    People, please stop adding comments for people to stop adding "+1" comments, and also please stop adding "+1" comments. There are like four useful comments in this thread. Not counting this one. Because this one is also not useful...

  9. Brett Brett

    I hope the title of this issue can be changed to "Remote pull requests between Google Code and GitHub" so it is two way, or, even better, "Remote pull requests between Google Code, GitHub, etc. via user-extensible standard protocol"

    A decentralized version control system deserves decentralized distribution and review options.

  10. Stanislav Spiridonov

    I think that feature have to be implemented from another side - provide some button to fork a project from bitbucket to github and follow them. It looks strange, but I hope it will allows users of github say - "Hey, looks on the cool feature on BitBucket, let's implement the same on GitHub".

  11. Waldir Pimenta

    This would be super helpful.

    As opposed to your comment :/

    Seriously guys, can we stop posting +1 comments and spamming this already long thread (and everyone's mailboxes) for no good reason? There is a vote feature, use it!

  12. Dan Bennett staff

    I realize this is a much requested feature, however, the likelihood of Bitbucket and Github or Github and Gitlab or Bitbucket and Gitlab working together to define a standard mechanism to present cross-system pull requests is exceedingly low -- at least for the foreseeable future. We've kept this open because it's not a bad idea even if we don't have high expectations of it happening, however, it has the unfortunate side-effect of creating false hope.

    I'm closing it now and we can re-open it if the situation changes.

  13. Jon Gorrono

    +1 - git has a long-ish history of using formatted patchsets applied with 'git am'. While not a pull-request per se., it would essentially reduce the protocol to SMTP and give a practical alternative that exploits canonical git language.

  14. Joshua Mostafa

    "...the likelihood of Bitbucket and Github or Github and Gitlab or Bitbucket and Gitlab working together to define a standard mechanism to present cross-system pull requests is exceedingly low"

    What if this feature - or the bare bones of it - was made a native part of git itself? Given that vendors have implemented it in their own ways with variations, it seems like an actual missing feature of git.

  15. Guillaume Séguin

    Hey Joshua Mostafa, I wanted to ask the same thing on StackOverflow or somewhere. Why is this not a native part of git is the real question.

    Of course, I don't the inner workings of git - still strugling with parts of it actually - so it might be easier said than done...

  16. Robert Watkins

    Consider what a pull request is - it's a method for Repo Owner B to request that Repo Owner A pulls a branch over from Repo B to Repo A. At the heart, it's about communication.

    To build that into git would be to build in a communication layer - this would be extremely difficult, and contrary to the spirit of git.

  17. ubul

    Am I the only one who considers this basically implemented in git itself?

    Let's discard the common misconception first about DVCS systems that big hosting sites host. DVCS stands for Distributed Version Control System. There is no git or mercurial related feature that any of them sites really provide on a code level. A DVCS does not need a central source of information. The entire idea of a DVCS is cloneability. Which pretty much eliminates ALL the differences as to what a DVCS repo can or cannot contain.

    Experiment at home with 2 virtual machines( 2 folders in the same machine would do the trick but let's just eliminate all the doubt by coupling environments on the network level) Install bare git. Read the documentation about mirror cloning write a cron job or a serverside hook to propagate to your 2 computer failover cluster any push events and fetch on the other node whenever a push event is propagated through your favourite messaging/event protocol. And voila you have your tesco value personal highly available git hosting solution. This is a simple case, which in this simplified form does not guarantee atomicity of operations on your 'remote' hosting solution. That requires some extra locking/waiting, which is beyond scope for something as simple as a pull request.

    In the dark ages when neither github nor bitbucket nor gitlab...etc existed or when one does not want to share their code with the public cloud people could do the exact same thing as a pull request by following this workflow: REQUESTER: 1. clone the original repo to get a working copy 2. create new branch based on an appropriate base branch(in most cases it is master but could be any really) 3. make changes and commit them locally 4. create an empty bare repository on their own publicly accessible server 5. add own server's git address as second remote to local copy 6. push custom changes to second remote 7. throughout the process he can pull/merge new changes in from original remote 8. negotiate credentials/cert with owner of the original repo and write them an email telling them you have some changes you would like to offer PULLER: 9. Author of original repository adds the requester's repository hosting uri and credentials to the remotes of his working copy configuration 10. checks out branch from foreign remote 11. merges locally with changes appeared since the last pull of the merge of the original branch to the forked one 12. checks tests/consistency/integrity/quality resolves issues with author via means of communication or amends code themselves 13. pushes to original remote 14. Answers email and thanks requester for the contribution

    I guess it is obvious why portals have seen a business opportunity in streamlining this 14 step workflow. But ultimately the feature they are providing is a composition of git primitive operations with some optimization/workflow sugar sprinkled all over it to make commenting and merging of pull requests less painful. Obviously there is room for making this process more disk-space efficient and faster that may include writing orchestration, custom git implementation or just a plugin to git. Gitlab for example keeps hold of all their additional fancy features and their settings in a satellite repository. They use it to resolve the metadata and merge of pull requests for example and annotate the diff with comments and whatnot. Conceptually their choice is understandable. git gives them the following programming concepts out of the box for free: Change detection Some diff capabilities and merge conflict resolution strategies(, although there are better tools you can use with git, such as P4Merge, which resolves more diffs in better quality than git does) Serialization of state Deserialization of state Cloneability, which is paramount to its distributed nature. Most of the cache-invalidation scenarios of distributed systems are already worked out in git.

    So all that is left to do is create a GUI, some event propagation system and some automated workflows that issue commands to git. Wire them into an API and distribute accross cloud cluster.

    For cross-site pull request there is limited extra work involved. Since the only common(and necessarily interoperable) grounds are the basic concepts of git there is no need to reinvent the wheel by creating an entire communications layer for each step of the above workflow. All they need is an adapter method that pulls in remote via git with credentials provided by the submitter, who obviously has an account in both systems.

    Consider: The fork part and the pull request part of this process is implemented in separate systems. But that should be no real problem. It is always the pulling system that needs to do the heavy lifting in git land anyway. Write simple adapter function to convert clone to fancy site-specific fork representation and diff + commitlog to fancy site-specific pull request representation. * Wire buttons on the site to use externally hosted git on the fork and the pull request workflow and to register foreign credentials such as generate a cert that we can use to set up read-only access on foreign repo....etc.

    On this level there is 0 collaboration on api and data structure needed because all this assumes is that a normal git client network interface would work with given site, which is obviously given since that is the point of them all. The only thing they should agree on is to provide these 2 obvious extensions to their workflows to help the case of community developed open source software in general. They might have to give up on some features given to them by the capability of capturing ancillary custom metadata during the forking period but the general viable pull request implementation is well within reach without having to even consider negotiating interfaces with other players of the industry.

    So guys don't point fingers. It is all up to each and every player of the code-hosting industry individually to facilitate accepting and using the well-defined common git interfaces in addition to the fancy workflow API. For example: the remote fork is mostly implemented in gitlab's import external repo feature. Except the relationship to the original is not maintained after that point.

  18. Christophe Faribault

    Could also just use 2 branches. Master on bitbucket, and a github branch with a different remote origin. You merge master into your github branch and push.

    http://stackoverflow.com/questions/15775183/git-different-remote-for-each-branch

    Or simply add something like this to your git config file after creating your "github" branch:

    [remote "github"]
        url = git@github.com:my-account/my-repo.git
        fetch = +refs/heads/*:refs/remotes/github/*
    [branch "github"]
        remote = github
        merge = refs/heads/github
    
  19. Log in to comment