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


Issue #8209 closed

Pull requests should go back to forked-from repo by default (BB-9378)

Martin Geisler
created an issue

I'm setting up a workflow where each developer has his own fork on Bitbucket. He pushes his changesets there and issue a pull request for someone to review the changesets before merging them back into the main repository.

It would therefore be helpful if the pull request screen would default to the main repo as the pull request destination. The named branch should also be kept as is: if I make a change on the stable branch in my repo, I want the change to be on the stable branch in the main repo too.

Generally, I think it makes little sense to issue cross-named branch pull requests with Mercurial. For Git or when using Mercurial bookmarks it makes a lot of sense, but named branches are meant for long-term branches where you don't merge on a per-feature basis.

Comments (6)

  1. Martin Geisler reporter

    Hey Zach,

    Yes, I found that pull requests works very poorly within a single Mercurial repository, please see #6705 for my findings on this.

    Even if they worked perfectly, it is nice to use separate repositories on the server for different things: I don't want see the work-in-progress from my coworkers before they're ready to issue a pull request. With a single repository, hg pull would bring in all branches from the main repository. I know Git works differently because you map remote branches as needed and git log works like hg log -r ::. by default. For Mercurial I don't think you want everybody pushing into one central repository.

    Finally, with separate repositories I can tell a coworker can change his mind and strip commits before issuing the pull request. That's much more cumbersome with just one repository since it is virtually guaranteed that others will have pulled the changesets. With a per-developer repository that risk is minimized.

    The risk of others having pulled the changesets will of course be removed when Bitbucket begins supporting exchanging obsolete markers — a feature under development in Mercurial that will allow you to push a refined (amended) version of a changeset and include information that says "this changeset makes the other changeset obsolete". Please see #4560 and #6710.

  2. Anonymous


    I can think of several reasons for Martin's proposed workflow:

    • the main/upstream repository need not contain cruft from abortive efforts of individual contributors (this is important for upstream maintainers and general users)
    • individual contributors don't need to deal with each other's cruft (this is important for contributors)
    • avoids permissions conundrum on the main/upstream repository; this is not only about clobbering each other's or upstream branches: eg. joe random contributor should not be able to create a branch called "stable" on the upstream repository.

    and so on.

    However, Martin's proposal has a problem IMO: The BB UI pushes users to base pull requests off named branches. So I'll have branches bugfix-1, bugfix-2, bugfix-3... And all of them should end up in "default" in the upstream. Defaulting the target branch to the source branch would be the wrong thing. A quick idea to improve it slightly:

    • if the target repository has a branch with the same name and at least one commit checksum (so it's not a naming collision), use that
    • else, use the branch of the merge-base (the commit that is in both repositories)
  3. Anonymous

    BTW, the whole pull-requests-are-named-branches thing is wrong in the Mercurial context. This is the one thing where you shouldn't have copied Git. IMNSHO.

  4. Martin Geisler reporter

    Roman, thanks for describing more excellent use cases!

    Like you write, the Bitbucket pull request pushes you to use named branches for each change. However, it didn't use to be like that! They've changed it very recently so that you can no longer select the head you want to merge when creating a pull request. I've written a longer comment on #6705 to explain the behavior I see now.

  5. Log in to comment