Sunsetting Mercurial Support in Bitbucket

Re:Sunsetting Mercurial Support in Bitbucket by strenholme on Tuesday August 20, 2019 @09:02AM (#20746453)

“a single proprietary solution Github by Microsoft”

Moving (Edit: Just the code, not issues and not pull request information) away from GitHub is trivial, since Git itself is open source and distributed, requiring merely setting up a repo on the new server (such as the open source Sourcehut) then running these commands:

    git clone https://github.com/foo/bar
    vi bar/.git/config # Add new remote location
    cd bar
    git push baz master

(Replace foo, bar, and baz with real names)

[ Parent | on HN ]

Re:Sunsetting Mercurial Support in Bitbucket by atombender on Tuesday August 20, 2019 @09:36AM (#20746826)

One-liner to change the URL of the upstream repo:

    git remote set-url origin <new URL>

[ Parent | on HN ]

Re:Sunsetting Mercurial Support in Bitbucket by Shorel on Tuesday August 20, 2019 @07:35PM (#20753324)

    # Add new remote location
    cd bar
    git remote add neworigin https://newserver.com/foo/bar
    git push --set-upstream neworigin master

[ Parent | on HN ]

Re:Sunsetting Mercurial Support in Bitbucket by ChrisSD on Tuesday August 20, 2019 @09:11AM (#20746552)

And what about the issue tracker? Issues and discussions of pull requests would be lost by merely moving the code.

[ Parent | on HN ]

Re:Sunsetting Mercurial Support in Bitbucket by michaelmure on Tuesday August 20, 2019 @09:54AM (#20747050)

I'm working on this, have a look at https://github.com/MichaelMure/git-bug

[ Parent | on HN ]

Re:Sunsetting Mercurial Support in Bitbucket by cabraca on Tuesday August 20, 2019 @09:58AM (#20747098)

you can import github projects including issues and stuff into gitlab

https://docs.gitlab.com/ee/user/project/import/github.html

[ Parent | on HN ]

Re:Sunsetting Mercurial Support in Bitbucket by strenholme on Tuesday August 20, 2019 @09:42AM (#20746900)

Some thing would be lost, yes [1] but the core code and commit history would be preserved. Issues can still be re-opened if still relevant, and pull requests can still be seen in the commit history. Comments on pull requests, if not approving a pull, will result in additional commits to the code which will be preserved.

Whether this is OK for a given use case depends on how important ticket and pull request comment history is. For open source projects, I don’t consider that kind of history nearly as important as the code itself, since a lot of issues are wishlist requests, support requests, or downright spam.

[1] Including branches unless one runs a script to go to and clone each branch to the new repo

[ Parent | on HN ]