Hg push tries to push data to repo without any changes

[Roman Kamyk jr]

Thanks for answer - but please take a look in the logs - the problem occurs
even when I do not use surepos, when I clone empty repository, hg out
doesn't show any changes, and yet hg push tries to push something...
Best,


On Wed, Jan 23, 2013 at 3:23 AM, Mads Kiilerich <mads at kiilerich.com> wrote:

>  On 01/23/2013 04:40 AM, Roman Kamyk jr wrote:
>
> Hi,
> I have a 'dotfiles' repo with couple subrepos, and have been using this
> fine for long time. Recently I migrated to a new machine, installed new
> Ubuntu 12.10, cloned the repo fine, but I am not able to push, because hg
> tries to push to one of the subrepos - that I didn't change, and I have no
> authorization to push on bitbucket.
> The problematic repo is https://bitbucket.org/tksoh/hgshelve, even
> without any subrepos there is a problem as ilustrated by new clone & push:
>
> rkj at rkjunior:~/tmp$ hg clone https://bitbucket.org/tksoh/hgshelve
> destination directory: hgshelve
> requesting all changes
> adding changesets
> adding manifests
> adding file changes
> added 46 changesets with 58 changes to 17 files
> updating to branch default
> 11 files updated, 0 files merged, 0 files removed, 0 files unresolved
> rkj at rkjunior:~/tmp$ cd hgshelve/
> rkj at rkjunior:~/tmp/hgshelve$ hg out
> comparing with https://bitbucket.org/tksoh/hgshelve
> searching for changes
> no changes found
> rkj at rkjunior:~/tmp/hgshelve$ hg push --verbose --debug --traceback
> pushing to https://bitbucket.org/tksoh/hgshelve
> using https://bitbucket.org/tksoh/hgshelve
> sending capabilities command
> bitbucket.org certificate matched fingerprint
> 24:9c:45:8b:9c:aa:ba:55:4e:01:6d:58:ff:e4:28:7d:2a:14:ae:3b
> query 1; heads
> sending batch command
> searching for changes
> all remote heads known locally
> no changes found
> preparing listkeys for "phases"
> sending listkeys command
> preparing pushkey for "phases:c3499427318a18f56b648dd92c253f93e422f42f"
>
>
> Mercurial is trying to push some phase changes. I guess that it in
> principle is the right thing to do.
>
> You can perhaps avoid that by setting a different phase locally. Or it
> could be considered a bug.
>
> (With the main bug being that you are using subrepos ;-) )
>
> /Mads
>



-- 
Roman Kamyk
email/jabber: roman.kamyk at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20130123/1f9ad7cb/attachment-0002.html>