Ability to create a pull request from a Mercurial bookmark

Issue #6705 wontfix
MattT
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.

Official response

  • Alastair Wilkes staff

    Hello all,

    Thank you for all of your feedback and comments on this issue, and we apologize for not engaging sooner.

    However, following a series of internal discussions, we have decided to close it as “won’t fix.” Instead, we recommend using named branches with Evolve.

    Over the past several years, named branches have become more powerful: in particular, Mercurial has acquired the ability to rebase and safely rewrite history. Our view is that named branches with Evolve offer a greater potential improvement to hg workflows than bookmarks, and we expect named branches will ultimately make bookmarks workflows redundant as they continue to improve and become even more popular. In addition to this trend, we wish to guide users towards a consistent, best practices workflow, and concurrently supporting several differing models does not support that mission.

    We have worked to help advance Evolve’s capabilities (this is what is making safe rebasing possible and generally empowers branch workflows), and, in addition, Atlassian made a financial contribution to the project last year to support its continued development.

    While Evolve has not yet landed in hg core, it is available for use in Bitbucket Labs. Once Evolve is available in core, we will enable it for all customers to use.

    To learn more about Evolve, check out:

    To enable Evolve support for your account's repositories, go to your account's Labs settings page and click the "Enables Mercurial evolution support" toggle.

    Thanks,
    Alastair
    Bitbucket PM

Comments (59)

  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. Anonymous

    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 @MattT 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 @MattT 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

    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

    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. Mantas Zimnickas

    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. Anonymous

    @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. Nathan Goldbaum

    Worth mentioning that @Sean Farley has added some support for opening pull requests from PR heads. It was always possible to do this, of course, but for a long time the bookmark name did not show up in the pull request dropdown menu.

    As of a few months ago, if a head in your repository has a bookmark on it, the bookmark name will show up in the pull request dropdown menu:

    Screen Shot 2016-01-13 at 10.58.46 AM.png

    In this case, I'm making a pull request from the "py3-notebooks" bookmark in my fork.

  20. Peter Hvidgaard

    I have 2 heads in the default branch, and they're both bookmarked. I get the impression from this thread that it's possible to create a pull request between the two, but it gives me the error

    The following error(s) occurred saving this pull request
    
        There are no changes to be pulled
    

    Is it still not possible to implement this (simple and realistic) workflow with bitbucket?

  21. Nathan Phillip Brink

    You have to create at least two bookmarks before it starts showing it in the pull request UI. I guess it works, but it would kind of be nice if it worked when there was only one too… I haven’t actually tried to finish making this PR, though…

  22. William Forson

    yep, still not working. I've got two bookmarks in my fork, but nothing bookmark-y is showing up in the pull request creation UI. any chance of getting this working in time for the ticket's 4-year anniversary?

  23. John Zhou

    I'm having the same issue as @Peter Hvidgaard. When I tried to create a pull request between 2 bookmarked branch heads on the same named branch it responds with "There are no changes to be pulled" even though the Diff says otherwise. It does work between a bookmarked branch head and a different named branch. So the only way I see of working around the problem is to create a named branch specifically to handle pull requests from bookmarked branch heads in another named branch...

  24. Pierre Augier

    I confirm that this old issue is very annoying... Is there any chance that you (Bitbucket staff) produce a fix for that soon?

    Note that when there is only one head in the branch of the main repository, it is worse because we don't see the bookmarks at all in the "create a pull request page". For example, if there is a bookmark master, we can not create a pull request from this bookmark (which is what we want) so we cannot see the message There are no changes to be pulled. The problem is then that the bookmark master is not updated and doesn't follow the tip of the default branch of the main repository.

    We would really need such master (or @) bookmark following the tip of the default branch of the main repository to easily update the cloned repositories to this point to start a new work.

    With these 2 "bugs", a workflow based on PR with bookmarks and forked repositories is really not straightforward.

  25. Alastair Wilkes staff

    Hello all,

    Thank you for all of your feedback and comments on this issue, and we apologize for not engaging sooner.

    However, following a series of internal discussions, we have decided to close it as “won’t fix.” Instead, we recommend using named branches with Evolve.

    Over the past several years, named branches have become more powerful: in particular, Mercurial has acquired the ability to rebase and safely rewrite history. Our view is that named branches with Evolve offer a greater potential improvement to hg workflows than bookmarks, and we expect named branches will ultimately make bookmarks workflows redundant as they continue to improve and become even more popular. In addition to this trend, we wish to guide users towards a consistent, best practices workflow, and concurrently supporting several differing models does not support that mission.

    We have worked to help advance Evolve’s capabilities (this is what is making safe rebasing possible and generally empowers branch workflows), and, in addition, Atlassian made a financial contribution to the project last year to support its continued development.

    While Evolve has not yet landed in hg core, it is available for use in Bitbucket Labs. Once Evolve is available in core, we will enable it for all customers to use.

    To learn more about Evolve, check out:

    To enable Evolve support for your account's repositories, go to your account's Labs settings page and click the "Enables Mercurial evolution support" toggle.

    Thanks,
    Alastair
    Bitbucket PM

  26. Sébastien GAUTRIN

    Edit: looking more around it, I'll amend my message, though letting the original below.

    It seems you are refering essentially to the “topic” part of evolve (which landed after I stopped having the opportunity to really use mercurial). However, you mention using named branches and evolve instead of bookmarks, while the evolve documentation about topics indicates that

    Topic branches are lightweight branches which disappear when changes are finalized (moved to the public phase). They can help users to organize and share their unfinished work.

    You should probably amend your message (as it is the resolution message visible at the top) to clarify that you mean using evolve topics in place of bookmarks and that those will be supported in the future; well, if that is what you mean. If you really meant using named branches and evolve instead of bookmarks, my original message still stands and we need more details on that new best practice workflow that Atlassian is recommending.

    However on that point, could they not be supported with the labs (unless they already are?)?

    To be noted though that the “won't fix” answer is not really satisfactory as the alternative is not yet available and this particular issue has been open for 6 years...


    Err? Having used evolve a lot in the past[1] and followed the evolve-testers mailing list during that time, I really fail to see how evolve is supposedly making the new best practice for mercurial to use exclusively named branches for short lived feature branches.

    Named branches in mercurial are not meant to be used for short-lived feature branches, that's what anonymous branches are for, and what bookmarks have been created for (although they have a lot of quirks).

    Our view is that named branches with Evolve offer a greater potential improvement to hg workflows than bookmarks, and we expect named branches will ultimately make bookmarks workflows redundant as they continue to improve and become even more popular. In addition to this trend, we wish to guide users towards a consistent, best practices workflow, and concurrently supporting several differing models does not support that mission.

    Care to expand on this and how named branches + evolve workflows are supposed to become the new best practice for mercurial? Aside of course for a squashing workflow, where named branches + evolve would work. Possibly with references to input from the core mercurial community (e.g. marmoute, or folks at mercurial or facebook using it).

    Granted I've barely used mercurial in the past few years due to being essentially forced onto git at work, but looking around quickly about such a workflow you are suggesting that would be the “best practice” with mercurial, I tend to actually find that it definitely not seems to be the case, if we look at the FeatureBranchesStruggle page on mercurial-scm wiki, where it clearly says

    Named branches are visible forever in the revision history, which makes them unsuitable for feature branch work as the feature branch names rapidly pollute the output of things like hg branches.

    or from the official documentation on workflows

    Note: If you have a huge number of small features (2000 and upwards), the number of persistent named branches can create certain performance problems. For features which need no collaboration or need only a few commits, this workflow also has much unnecessary overhead. It is best used for features which will be developed side by side with default for some time (and many commits), so tracking the default branch against the feature is relevant. To mark single-commit features as belonging to a feature, just use the commit message.

    Note: The difference between Mercurial named branches and git branches is that git branches don’t stay in history. They don’t allow you to find out later in which branch a certain commit was added. If you want git-style branching, just use bookmarks.

    Yeah, no, definitely it does not seem like mercurial community thinks that using named branches for feature branches is a good thing, even with evolve in the picture.

    TL;DR: please, please explain in depths how people are supposed to use named branches + evolve instead of bookmarks, considering that's what Atlassian recommends now, as it is definitely not something that's out there and from where I sit, this definitely does not answer the initial issue.

    Note: your first link is incomplete, it should be https://bitbucket.org/blog/edit-history-with-mercurial-evolve-beta-in-bitbucket-cloud


    [1] essentially from before the request to support exchange obsolescence markers in bitbucket with issue #6710 until a little more than a couple years ago; yeah, unfortunatetly I've been forced out of mercurial onto git before bitbucket ever had proper support for experimenting with evolve :/

    quick timeline for perspective:

    • Mercurial 2.3 (2012-08-01): obsolescence markers in core
    • Mercurial 2.5 (2013-02-01): hidden changesets properly handled by all commands
    • issue #6710 (2013-03-17): request for supporting obsolescence markers on bitbucket, dependent on upgrading mercurial from 2.2 to more recent on the server
    • mercurial 2.9 on bitbucket: somewhen before 2014-11-14
    • issue #6710 fixed in labs (2017-03-09)
    • 2019-01-25: new best practice for Atlassian is to use named branches + evolve instead of bookmarks
  27. Zoltán Lehóczky

    Slightly off: as a hg user with repositories having 7+ year histories I don't see the issue with using named branches for feature/issue branches. At my team we're using branches like this as well, for every single issue, and there are no downsides I've experienced (performance, usability or otherwise) if you close branches that aren't needed any more (you can reopen the if the need arises later).

    I'm not saying a large number of named branches can't be a problem in your team in particular, but it's also not something you need to absolutely avoid for feature branches.

  28. Andrej Shadura

    I guess what Alastair is referring to is that what using evolve, AFAICT you can redact the branch name when rebasing in on the main branch, and the obsolescence markers will make sure other users who’s pulled the original branch will be directed to the new commits on the main branch.

  29. Nick Coghlan

    I concur with Sébastien's comment above - it's fine to say that Atlassian's recommended workflow for Mercurial PRs is to use named branches with evolve (or perhaps the recommendation is specifically to use topic branches?) rather than bookmarks, but there are a few other things that then need to go with that:

    • documentation on how to actually do it, since most generally available Mercurial docs still say to use bookmarks for throwaway git-style working branches (those docs will need to cover getting evolve set up on all client machines, since Mercurial still locks it away by default)
    • a way to convert a pushed bookmark into a named branch (or topic branch?) in order to make a PR from it (or else a way to prevent bookmarks from being pushed in the first place)
    • a Mercurial-PRs-for-git-users crossover guide

    Evolve is an excellent piece of tech (I saw Matt Mackall give a quick demo of it a few years back), and it's very cool that Atlassian are actively investing in making it better, but the default UX that BitBucket Mercurial repos are offering in this area is currently still quite poor, and it isn't at all clear what the end state is expected to look like.

  30. Log in to comment