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

Issues

Issue #8678 closed

"Draft" status on commits (BB-9791)

Legalsense
created an issue

Our commits (private repo) are showing up as drafts as of recently.

It appears to be the same issue as described here, except that none of the solutions provided there seem to work.

http://stackoverflow.com/questions/20648510/draft-commits-on-mercurial

specifically, I tried turning "This is a non-publishing repository" on and off.

I'm not aware of using "phases".

Comments (55)

  1. NRG Admin

    We're seeing the same behavior on one of our repos:

    https://bitbucket.org/nrg/xnat_builder_1_6dev/commits/all

    The commit that is currently in draft state is:

    https://bitbucket.org/nrg/xnat_builder_1_6dev/commits/af53ee218079c9720537af1c0beae315466b6460

    I did the merge of the pull request same as we've always done, and now it's a "draft" with no explanation of what that means and no indication of how to make it not a draft. When I do "hg incoming" on my local repo, the "draft" merge shows as an incoming change, so I'm not sure what's really different.

  2. NRG Admin

    This looks to be a bitbucket issue, not necessarily a Mercurial issue. Working from Jesse's suggestion above, I tried to run that command, specifying the revision of the changeset explicitly. That gave me the following:

    rherrick@Aerys:~/Development/XNAT/1.6/xnat_builder_1_6dev$ hg phase --force --public -r 2306
    no phases changed
    

    I repeated this with the 7-character checksum, then the full 40-character checksum with the same results.

    So I tried to check the phase of the changeset that bitbucket is showing as being draft:

    rherrick@Aerys:~/Development/XNAT/1.6/xnat_builder_1_6dev$ hg phase -r 2306
    2306: public
    rherrick@Aerys:~/Development/XNAT/1.6/xnat_builder_1_6dev$ hg phase -r af53ee2
    2306: public
    rherrick@Aerys:~/Development/XNAT/1.6/xnat_builder_1_6dev$ hg phase -r af53ee218079c9720537af1c0beae315466b6460
    2306: public
    

    So my local repo thinks it's public, it's showing up just fine, but on bitbucket it's showing up differently:

    Draft changeset

    It was saying "Draft" before, but now it's not, it's just grayed out and weird looking. So... no idea what's going on with it.

  3. Josh Baker

    When committing from the web, the commit shows up as a draft, but it seems to clear itself up after about 15 minutes.

    NRG Admin that specific commit (af53ee2) is a merge commit, so Bitbucket will show it grayed-out since it isn't important.

  4. Legalsense reporter

    Actually, yes, this clears itself up after a while.

    Not sure what "committing from the web" means - I'm committing using my CLI, but viewing using the web UI.

  5. Joseph Kenny

    Yep, we've got the same problem. Commit pushed to bitbucket repo via CLI listed as a draft on the bitbucket commits page. But hg phase <cs> lists it as public, so I believe our repos are fine, bug in the web source browser or some such thing.

  6. Brodie Rao

    This should be fixed going forward.

    We actually had a longstanding issue where we were incorrectly marking changesets Bitbucket made (and changesets pulled through PRs) as drafts. It's only recently when we started exposing draft information that it became apparent.

    I've put out a fix that makes Bitbucket commit/merge PRs with the proper phase. As you push to your repos (or make new commits), you should see the draft commits become public.

  7. Jeff Hinrichs

    Me Too --- draft status on commits in my repo ---arrgh, via the cli no less, not using the web interface. Displaying on commit happening since Jan 31, 2014 -- just noticed it now -- I swear that was nothing about "Draft" on Friday. Feb 7.

  8. Slavita Baciuna

    We are experiencing the same problem on several of our repositories(commits marked as drafts on repositories that do not allow drafts).

    Are there any workarounds for this problem? (we tried turning "This is a non-publishing repository" on and off and it did not work)

    Do you have any information in regards to when this will be fixed?

    Thanks

  9. Islam Elnabarawy

    I'm experiencing the same issue, but somehow it happened for the last series of commits and not the ones before that.

    The repository was created today and there were commits on it done by myself and a team mate, and only the last group of commits done by myself have this Draft status.

    Screenshot:

    Capture.JPG

    Edit: Commits were done locally and pushed via TortoiseHG on Windows 7 64-bit, in case that's relevant.

  10. David Winter

    Experiencing the same issue. We created a new repo today and pushed a local repo which is running a really old version of Mercurial (1.2.1) that doesn't even support phases, and once pushed up to Bitbucket, the commits are marked as draft.

    Can someone from Bitbucket please comment? Will this cause issues for us? Is it just cosmetic? Or...?

  11. David Winter

    Have just noticed that the commits are now no longer appearing as draft. Looks like this happened at the same time the change to fade out merge commits was deployed. Unless I'm going mad, that happened since I last commented.

    Thanks guys! Avoids a lot of confusion for us.

  12. Islam Elnabarawy

    It seems like this issue may be triggered by pushing commits made from an older Mercurial version. I noticed that in our repository, when I pushed my commits they were marked as Draft, but when my colleague pushed her commits they weren't, and they even caused the Draft status to be removed from my earlier commits. I checked and found she was using the latest TortoiseHG with Mercurial 2.9, so I updated mine and the problem no longer happens.

    Hopefully this helps track down the issue, or at least help other people work around it.

  13. kritisen

    I noticed the same problem today.

    I tried "hg phase --force --public -r XX" and found that my Mercurial version on my local computer had not been updated in a while.

    Updated Mercurial.

    Then did a minor edit, commited, and pushed back to the repo.

    "Draft" signs are gone :)

    UPDATE: After posting, I noticed that Islam (2 comments above) found the same solution. Why does bitbucket forum not get a stackexchange kind of voting system so that best answers surface to the top?

  14. Scott Natelli

    I just ran into this issue on Friday, April 18th, on a repository that I have been using for a while with older v2 Mercurial clients. The series of commits displayed with the draft status were all committed and pushed with the same client.

    Draft_Commits.png

    I did not change any of the settings on the repository since I created it or on any of the preexisting client systems I had before this latest push. The draft status appeared when I pushed commits from a machine that had a brand-new installation of Mercurial and TortoiseHG installed on it; v2.9.2 and v2.11.2 respectively.

    So, the issue can't be solely caused by an out of date client like has been mentioned in the other comments, since mine were caused using the most recent Mercurial version. Also, since this issue was opened last year, I just wanted to add that none of my repositories exhibited this behavior until this incident last week. In addition, the affected repository is the only one I have touched in the past couple of months.

  15. Scott Natelli

    I made another push today to the same repository I mentioned in my earlier post, and using the exact same client as well. However, the new commits did not have the draft status on them, and the commits from the 18th no longer have the draft status either.

    New_Commits.png

    The only setting in TortoiseHG I changed today, was the security options when I went to push to the repository; I set the Secure HTTPS Connection to No host validation, but still encrypted (bad). I made this change because I was experiencing the following error, and the solution mentioned in the blog post did not resolve it.

  16. Reinoud van Santen

    This problem suddenly started in one of my private repo's somewhere between 21-05-2014 and 27-05-2014. No changes to the repository where done. hg phase --force --public . on my repo says that no phases where changed. I just changed the setting of the repo to non publishing but I don't know if that's going to fix the problem because no commits have been pushed yet.

  17. Jan-Philip Gehrcke

    I find this annoying, but I have seen this issue come and go in my repos, and it has never actually been an actual problem. My guess is that bitbucket has various kinds of batch jobs, modifying (and possibly auto-correcting) all repos (or at least the web abstraction of them) in this respect from time to time. That would explain the time scale we see things change, as well as that we almost never can correlate these changes with actions on our sides.

  18. Martin Geisler

    To everybody suggesting running hg phases --force --public .: you never need force when you change the phase from secret to draft or from draft to public. This direction is the default direction, so you can safely leave out --force. (You should in general never use a --force flag without reading up on what it does first.)

  19. Rudey Yao

    Found my newly imported HG repo all with 'D' flag - the reason is I'm using an out of date HG client. Using 'hg push' with latest client and after that all 'D' flag disappeared.

  20. Marcus Bertrand staff

    Hi all,

    Please ensure you are running the latest version of Mercurial. Older versions of Mercurial may be incompatible with the newer phases. The issue here should be resolved as of quite some time ago. I will place this issue on hold for now. If, after upgrading the Mercurial client on your machine, you still see this issue, please come to support@bitbucket.org with the full details of your repo with the issue and we'll take a look.

    Thanks,
    Marcus Bertrand
    Bitbucket Developer

  21. Gustavo Homem

    This is happening to me on a repository that does NOT have the "this is a non-publishing repository" checkbox set. I'm using lastest mercurial version from Ubuntu 12.04 and that should work given the "this is a non-publishing repository" checkbox is not set.

  22. seth

    -1 on changing the default for new repos to non-publishing.

    I want my repositories to be publishing by default. I was very confused as to why I had draft changesets in my repository.

    The wiki/docs (https://www.mercurial-scm.org/wiki/Phases) even say that repositories are publishing by default and that is what I would expect (and is IMO the intuitive behavior).

    Regardless to fix my repos I had to do the following:

    hg phase --public .
    hg push
    
  23. Sean Farley staff

    It doesn't really make sense as the default because you can't go from public to draft. You can, as you've seen, go from draft to public. Ever since the phases concept was introduced in 2.1, the default for new repos is actually non-publishing (unsetting HGRCPATH to show that this is the default behavior):

    $ export HGRCPATH=
    $ hg version
    Mercurial Distributed SCM (version 2.1)
    (see http://mercurial.selenic.com for more information)
    
    Copyright (C) 2005-2012 Matt Mackall and others
    This is free software; see the source for copying conditions. There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
    $ hg init hg-test-phase && cd hg-test-phase
    $ echo a >> a; hg ci -Am init -u smf
    adding a
    $ hg phase .
    0: draft
    

    It's also trivial to set your repo as publishing: just check the box in the settings page of the repo. On the next push, everything will be marked public.

  24. Milan Brezovsky

    This change is really annoying, because 99% of people don't have any need to have their repos to give them all commits as drafts, and now I need to instruct all developers in my company to uncheck your newly-changed default setting.

    Until I found this ticket and fixed things, every time I was reviewing my commits before pushing, it was unclear which ones are local and which ones are published, because the published commits are counter-intuitively marked as drafts.

    So I needed to go and change 8 repos and one by one reverted your dumb change into our "doesn't-make-really-sense" default.

    I literally cannot imagine a use case for receiving commits from bitbucket from my other coworkers that I would want to see marked as drafts.

  25. Milan Brezovsky

    From the Mercurial documentation, because I'm angry that you wasted my time with this:

    • The draft phase holds changesets that are not yet considered a part of the repository's permanent history. You can safely rewrite them. New commits are in the draft phase by default.
    • The base rule is very simple: "Any changesets seen in a remote repository are public"
    • 5.0.3. Why is "publishing" the default? We discussed above that any changeset from a non-phase aware repository should be seen as public.
    • As in the choice for default, the main reason to allow draft changeset in publishing server is backward compatibility.

    In other words, you brought up an obscure use of Hg and made it default. Congratulations.

  26. Steve Eynon

    I agree, this draft changeset default is obscure. I've been forced to learn about phases only because of this ticket.

    I've been wondering for a long time why in eclipse, my newer repos are marked as never been pushed (which is really annoying). After testing today, I found it's because my eclipse Hg plugin doesn't understand draft changesets.

    I never understood, or cared, what the new This is a non-publishing repository checkbox was all about. Now I have to.

    Backing up Milan Brezovsky, the checkbox also says:

    For more information, see hg help phases.

    So I did. And lo and behold, it encourages publishing servers:

    C:\>hg help phases
    Mercurial Distributed SCM (version 4.1.1)
    ...
    
    Phases and servers
    ==================
    
    Normally, all servers are "publishing" by default. This means:
    
     - all draft changesets that are pulled or cloned appear in phase
          public on the client
    
     - all draft changesets that are pushed appear as public on both
          client and server
    ...
    

    A different, but related, issue is the confusing double negative English in the UI settings:

    Uncheck if you don't want to non-publish by default...?

  27. Sean Farley staff

    This change is really annoying, because 99% of people don't have any need to have their repos to give them all commits as drafts

    That is in no way true. It's closer to being the opposite percentage, honestly.

    and now I need to instruct all developers in my company to uncheck your newly-changed default setting.

    Or you could just mark the 'default' branch public every so often (e.g. hg phase --public default). This is currently, the best option available in a Mercurial workflow. We've talked about marking pull requests as public once merged. That would basically require (more or less) a named-branched workflow.

    Until I found this ticket and fixed things, every time I was reviewing my commits before pushing, it was unclear which ones are local and which ones are published, because the published commits are counter-intuitively marked as drafts.

    That's not really the purpose of draft commits. Draft commits are those that can be edited (via the evolve extension). That's one of the reasons remotebranches and remotenames (my own fork of Augie's work to support bookmarks; unfortunately, I made some changes to defaults that I now regret). Having the remote name is extremely useful and will get into core Mercurial fairly soon.

    So I needed to go and change 8 repos and one by one reverted your dumb change into our "doesn't-make-really-sense" default.

    You don't need to name-call.

    I literally cannot imagine a use case for receiving commits from bitbucket from my other coworkers that I would want to see marked as drafts.

    The reason is to pave the way for mutable history with the evolve extension (e.g rebase, histedit). You can read more about it in my recent blog post about releasing evolve as a beta feature.

  28. Sean Farley staff

    From the Mercurial documentation, because I'm angry that you wasted my time with this:

    I'm sorry your time was wasted.

    • The draft phase holds changesets that are not yet considered a part of the repository's permanent history. You can safely rewrite them. New commits are in the draft phase by default.

    This is true. Draft commits are those that can be safely rewritten.

    • The base rule is very simple: "Any changesets seen in a remote repository are public"

    See below.

    • 5.0.3. Why is "publishing" the default? We discussed above that any changeset from a non-phase aware repository should be seen as public.

    The key here is non-phase aware. Bitbucket is now well aware of phases and can (beta) safely mutate them.

    • As in the choice for default, the main reason to allow draft changeset in publishing server is backward compatibility.

    Yes, that was true to help migrate servers using old versions of Mercurial. Bitbucket has been keeping up-to-date with Mercurial for a while now.

    In other words, you brought up an obscure use of Hg and made it default.

    I only changed things to the workflows that Mercurial itself are using (and gradually moving everyone towards). Evolve will one-day be on by default. Phases have been draft by default for years now.

    Congratulations.

    Thanks! It was a lot of hard work (especially with writing that blog post!).

  29. Sean Farley staff

    I agree, this draft changeset default is obscure. I've been forced to learn about phases only because of this ticket.

    It was inevitable at some point. This has always been the plan of Mercurial: safe, mutable history.

    I've been wondering for a long time why in eclipse, my newer repos are marked as never been pushed (which is really annoying). After testing today, I found it's because my eclipse Hg plugin doesn't understand draft changesets.

    The eclipse plugin is using the concept of phases incorrectly, I would say.

    So I did. And lo and behold, it encourages publishing servers:

    Ah, thanks for pointing that out. I'll have to submit a patch for that.

    A different, but related, issue is the confusing double negative English in the UI settings:

    Whoops, good catch. I'll make a todo for myself to fix that.

  30. Milan Brezovsky

    Sigh. I apologize for getting emotional and being rude. I guess you know better how BitBucket users are using Hg.

    It still seems counter-intuitive for me, because I don't want the history to be mutable. Once pushed to the BB repository, I can rest assured that the public changesets are visible in the same way to everyone. What's in default gets deployed to production, so I definitely don't want sneaky history changes. Append-only architecture is much easier to read, and easy to read in software development means less bugs, means happier customers. If you really believe mutable history is the future, then I would appreciate either, or both of the following:

    • always marking merged PRs in default as Public (as you suggested)

    • having a global org setting that will mark all new repos with This is a non-publishing repository set to off.

    Honestly though, hg contributors insist this is the future, then I would welcome "local draft" phase, to mark commits that have never been pushed/pulled from anywhere. Yes, I know I can do hg out, but that's just awkward.

    Overall, I would argue that history editing is an anti-pattern, because it makes it harder to see the development process - often you get into situations where you need to debug someone else's code. Seeing their commit history, together with all the mistakes and typos, helps you understand their thought process, goals, biases, mistakes. Explicit changes are always better than sneaky ones.

  31. Gary Kramlich

    It still seems counter-intuitive for me, because I don't want the history to be mutable. Once pushed to the BB repository, I can rest assured that the public changesets are visible in the same way to everyone.

    I use my mainline repo to do this. It's a publishing repo so all pull requests to it get marked as public while all forks are non-publishing. This way pull requests can be edited until everyone is happy, and once they're merged to the mainline repo, they're published and we're good to go.

    Not sure if that'll work for your workflow, but you can see it in practice. The mainline publishing repo is https://bitbucket.org/pidgin/main and my non-publishing fork is https://bitbucket.org/rw_grim/pidgin.

  32. Sean Farley staff

    Sigh. I apologize for getting emotional and being rude. I guess you know better how BitBucket users are using Hg.

    No worries :-) I also have bad days, so no harm, no foul.

    It still seems counter-intuitive for me, because I don't want the history to be mutable. Once pushed to the BB repository, I can rest assured that the public changesets are visible in the same way to everyone. What's in default gets deployed to production, so I definitely don't want sneaky history changes. Append-only architecture is much easier to read, and easy to read in software development means less bugs, means happier customers.

    That's a good policy and I quite agree with that. As Gary Kramlich suggested, one way to achieve this in a fork-based workflow is to set the canonical repo as publishing and then the phase will naturally propagate.

    Another feature we could add is that the 'main branch' (a bitbucket thing, but usually 'default') could become public on merging a pull request. I've thought about making the main branch as always publishing but that would require all Mercurial users to use a named branches instead of bookmarks. Perhaps that what we should do but it requires some thought.

    Ultimately, this is a sore spot in Mercurial (outside the use of Bitbucket). I've thought of ideas of a new type of branch that will fix this but it's just a prototype for now.

    Honestly though, hg contributors insist this is the future, then I would welcome "local draft" phase, to mark commits that have never been pushed/pulled from anywhere. Yes, I know I can do hg out, but that's just awkward.

    I think lots of people are in this boat and that's why something like 'remotebranches' will be in core soon.

    Overall, I would argue that history editing is an anti-pattern, because it makes it harder to see the development process - often you get into situations where you need to debug someone else's code. Seeing their commit history, together with all the mistakes and typos, helps you understand their thought process, goals, biases, mistakes. Explicit changes are always better than sneaky ones.

    Indeed. But more commonly is the situation where a project requires each commit pass build status. Editing your own branch to ensure that makes a lot of sense in that case. For sure, this is something Mercurial (and I will help as much as I can) needs to smooth over.

  33. Log in to comment