Issue #6705 open

Can't create pull request from hg bookmark (BB-7853)

Matthew Turk
created an issue

On "compare view" I can select a bookmark from the dropdown on a fork, but I can't create a pull request from that bookmark. Going to the pull request UI, I can create a pull request from a changeset that happens to be a bookmark, but there's no bookmark section in the dropdown -- only named branches.

It would be great to have bookmarks in the Pull Request dropdown and to be able to create a Pull Request from a bookmark in the compare view. Since these are somewhat analogous to "feature branches" it would also be nice to be able to close/delete them on PR, like branches.

Comments (35)

  1. Martin Geisler

    I just tried this out again and noticed that it's a bit more annoying that I thought: I cannot even create a pull request after manually selecting the head (bookmark) I want to merge into default. The create pull request button simply doesn't do anything. There is no error message either.

    In short, trying to merge two heads on default with each other doesn't seem to work. Neither head is an ancestor of the other, so there is something to merge.

    It would have been a good start if I could just select the revisions to merge from and to freely and manually, but there seems to be too much logic in the form :-)

  2. roman.neuhauser

    i'm curious about one thing: as far as i understand it, the workflow endorsed by bitbucket (named branch per pull request) goes straight against the mercurial documentation: "don't treat branch names as disposable", so let's say the mercurial authors know their code, and creating a branch name for every pull request is "using it wrong". where will i get support if mercurial hits some performance or correctness limits thanks to a few thousand closed branches?

  3. Martin Geisler

    Having many (closed or not) named branches wont cause any correctness problems. It's mostly a UI problem: programs often put all named branches into a drop-down which then becomes very, very, big if you have a couple of thousand branches.

    You can try cloning my 10k test repository and play around. It has 10,000 named branches so it should be a good example of how a repository can look after many years of intensive use.

    (I notice that there are 22 watchers for this issue, but only 4 votes for it — it should be the other way around! So please vote for it if you haven't already.)

  4. Albert Graef

    I notice that there are 22 watchers for this issue, but only 4 votes for it

    That might be because ppl are still trying to figure out how the issue affects their workflow. :) Anyway, I cast my vote now. I'd really like to see this fixed.

  5. Martin Geisler

    So, I went back and re-tested this after Matthew Turk wrote me that he can create pull requests between different clones and that he can have multiple pending pull requests between two repositories.

    What I found is:

    • Pull requests inside a single repository is still broken like described above.

    • Pull requests between repositories work:

      • The "Create pull request" view doesn't know about bookmarks, but you can select a head by its changeset hash.

      • No matter what head you select, the Commits tab will show a preview as if you're selected the branch tip (most recent commit on the branch).

        Looking at the AJAX request being made explains it: no matter what head you select, the request being made is /user/fork/compare/branch..user/repo:default, that is, it is based on branch names instead of the actual head selected.

      • Clicking "Create pull request" works despite the broken preview!

    • The compare view between repositories mostly works:

      • It knows about bookmarks.

      • The preview of in the Commits tab is correct.

      • When selecting a bookmark, the "Create pull request" button becomes inactive and you cannot create a pull request.

      • Selecting the same head by changeset hash allows you to create a pull request.

      • The pull request has the wrong preview in the Commits tab.

    So it seems that there is two small problems here: the Commits tab in the pull request view only uses the branch name when fetching the preview and the compare view doesn't allow one to create a pull request after selecting a bookmark. Let's hope the good people at Bitbucket can track those bugs down!

  6. tchamberland

    +1, following.

    I feel like creating requests based on branches or bookmarks should simply be an abstraction over doing it from the actual changeset hash itself. By default, I should be able to click on any commit hash in the log, go to the diff and create a pull request from there. Using bookmarks or branches is only abstraction on top of that.

  7. Johannes Dewender

    Martin Geisler wrote:

    The "Create pull request" view doesn't know about bookmarks, but you can select a head by its changeset hash.

    How exactly can you select a head by its changeset hash? In bitbucket.org/<username>/<repo>/pull-request/new I can put hashes in the branch field, but they are not accepted. Meaning the selection still stays on the branch, the search tooltip doesn't close (saying No results match ...) and I am still on the branch (selecting the latest head/tip, mostly another bookmark).

  8. Johannes Dewender

    Okay, so now I could at least reproduce how one can compare a bookmark to something:

    You have to go to the commits tab and then select the bookmark you want. This shows up in the url then as .../commits/branch/test1 with test1 being a bookmark. When you go to "compare" up in the toolbar now (the link didn't actually change, according to my FF status bar), it will lead you to the standard compare ui but forward to .../compare/test1.. almost immediately and automatically. (which is a wtf in itself). You can then change the target repository to view the difference. Like Matthew Turk said, you can't click on "pull request" right there.

  9. Johannes Dewender

    You can try and change the pull request url to force a specific commit in the branch, but that also doesn't work (except when the commit/bookmark is also the tip of the branch!)

    Details: A pull request url looks like this: bitbucket.org/<user>/<repo>/pull-request/new?source=<user>/<repo>:<hash>:<branch>&dest=<user>/<repo>::<branch>;

    When you do create a pull request from your default to the default branch of another repo, the <hash> is set to the tip of your default branch. Changing that hash to the bookmark (part of the default branch) you want does not seem to help. Not only the preview still shows the differences between your tip and the tip of the other default, but also the final pull request.

    Sorry, but what I got from lots of testing today is that using bookmarks in pull requests doesn't work at all. Not with inserting hashes in the UI and not with inserting hashes in the URL.

    This might seem to work when the bookmark you want is currently the tip of the default branch, but then you are not actually working with the bookmark, but with the tip of the default branch.

    If my observations are incorrect, please do tell me.

  10. Martin Geisler

    Johannes Dewender They changed this! I noticed today that the dropdown in the pull request view no longer has entries for the different heads of a named branch...

    It used to list each head as separate entries. The heads were listed by their changeset ID, but I could live with that. When you selected a head, the preview of the commits was wrong since it always used the branch tip instead of the selected head. The pull request itself was created correctly, though, so I could live with that too.

    Now I can only choose the branch tip (head with highest revision number). That means that the only way to create multiple pull requests is to make them right after pushing each head: push first head, create first pull request, push second head, create second pull request, etc.

    Brodie Rao and Erik van Zijst : I guess you are working in this area after all? Great! Please try not to regress this further :-)

  11. Brodie Rao staff

    That regression should be fixed now. Sorry about that.

    Also, if it's any consolation, hopefully sometime next week we'll be putting out support for choosing different destination branch heads. It's not proper bookmark support, but it's one step closer.

  12. tchamberland

    Ideally both. I should be able to choose any changeset that isn't in the source repository and create a pull request from it, not just heads. The receiver should then be able to choose which changeset it get's merged into (destitination).

  13. Johannes Dewender

    Thx Brodie Rao. I can test this just fine now. Choose a head for a pull request (listed as default (<hash>)), create pull request. When I update that head, I can even update the pull request (popup telling me there is a new commit, update) like with "normal branches".

    This breaks when the commit I chose for the pull request is again included in two heads, since the pull request saves the hash, not the (name of the) bookmark.

    Saving the hash also means: Having pull requests for bookmarks that currently are not on (the tip of) a head is not supported.

    Example: I fork and get a default branch. Then I bookmark the head as "main" and commit stuff (moving the main bookmark along). Now I actually branch off a "feature1" bookmark and do some commits there. I still got 1 head only, but two "branches"/bookmarks. I would like to be able to open a pull request for "main", which currently isn't a head, but can be after updates.

    These two things are still missing in order to get a usable workflow for projects that chose mercurial as their SCM. I am always told "just use bookmarks, they are like git branches" and then I have to tell them that this just isn't supported on bitbucket in any way similar to how git branches are supported. Which is weird, since bitbucket started out with mercurial-only.

  14. Brodie Rao staff

    You're totally right, Johannes. Right now when you one-click update a PR, we choose an arbitrary descendant of the current source commit that's on the same named branch. That can cause you to update to the wrong head if you've branched off from that source commit.

    You can work around this by updating the pull request by clicking "edit" and manually choosing the right head.

    Note that the support I'm adding for choosing destination branch heads will work the same way and have the same limitations.

    These two things are still missing in order to get a usable workflow for projects that chose mercurial as their SCM. I am always told "just use bookmarks, they are like git branches" and then I have to tell them that this just isn't supported on bitbucket in any way similar to how git branches are supported. Which is weird, since bitbucket started out with mercurial-only.

    To give you some back story on this: We launched pull requests in June of 2011. At the time, Mercurial only very recently made bookmarks a built-in feature, and we (the Bitbucket team) weren't using them internally. We designed pull requests around making forks and doing PRs between them. You could pick any head as the source commit, and you could choose a destination branch the parent repo to merge it into.

    After we launched Git support, we updated pull requests so they tracked the source by branch and added support for intra-repo PRs. Since then, we haven't made any substantial changes to how PRs work.

    I think if bookmarks were more popular at the time we started the feature, we would've added support for them. But, at least for now, revisiting pull requests isn't on our immediate development road map.

    Also, I should mention that one technical aspect that's held this up (and made it a bigger undertaking than it probably should be) is that everywhere in our pull requests code we only look at the branches namespace. If we start looking at bookmarks as well, we'll need to have proper namespacing between the two. As a compromise, we could make it work in a way that if you have a bookmark that shadows a named branch, you can't use that named branch in a pull request. Either way, it's a significant undertaking.

    I can't make any promises as to when we'll add bookmark support, but I can say this: there's a Mercurial developer sprint coming up soon. I've been known to do a little Bitbucket development in between hacking on Hg when I'm at those. I might look into implementing it myself when I'm there (in addition to upgrading us to the latest version of Hg and enabling proper changeset evolution support).

  15. anatoly techtonik
    I notice that there are 22 watchers for this issue, but only 4 votes for it
    
    • 2013-08-26 - 22 watchers and 4 votes
    • 2014-01-03 - 60 watchers and 62 votes
    • 2014-02-12 - 71 watchers and 73 votes

    Seems like HG bookmarks are gaining popularity. I can only say for myself, that FUD around HG named branches gave it a bad reputation. The explanation that the only problem with them is the huge list of names in drop-down lists should be on the top page of Mercurial docs somewhere.

  16. sirex

    Now it seems, that some how it is possible to use bookmarks for pull requests, but bookmark name is not always show, bookmarks are listed as branches in overview page, but not in branches page. You can'd create pull request from branch page, but it is possible to create pull request from bookmark from pull request form page (only bookmark name is not shown).

    Overall, actually I managed to create pull requests from bookmarks, but bookmark support looks like half done.

  17. ruarc

    Any update on this? These things seem to have a horrible habit of going dead. I'm not too convinced that Mercurial workflow support is a big priority these days.

  18. roman.neuhauser

    ruarc i don't think the lack of commitment from atlassian is mercurial-specific. they seem to have thrown the towel in re github competition, bitbucket.org has basic, easy to solve issues in the UI, and they haven't addressed those in many months at least.

  19. Log in to comment