hg push to github fails

98 views
Skip to first unread message

lsces

unread,
May 2, 2011, 6:58:46 AM5/2/11
to hg-git
I'm seeing a previous unanswered thread about this, but can't reply to
the hence a new thread.

I currently have hg 1.8.2, TortoiseHg 2.0.3 Dulwich 0.7.1 and I think
the latest hg-git. With a previous setup which I can't seem to
recreate now I was quite happily pushing to gitub.com/lsces and the
source repo's, but now I'm not getting anything actually pushed.

I can create error messages by trying various -r and -b options, but a
straight push either via command line or via TortoiseHg is just saying
completed without an error. But nothing is showing in github. Where am
I going wrong?

Mads Kiilerich

unread,
May 2, 2011, 5:32:46 PM5/2/11
to hg-...@googlegroups.com, lsces

Did you put a bookmark on the heads you pushed? git and github requires
that.

/Mads

lsces

unread,
May 2, 2011, 5:58:42 PM5/2/11
to hg-git
On May 2, 10:32 pm, Mads Kiilerich <m...@kiilerich.com> wrote:
> Did you put a bookmark on the heads you pushed? git and github requires
> that.

Well the repo had been cloned from github, and the updates sorted
locally, so the 'master' bookmark was still in place, but 'moving' it
seems to have unjammed things, and the github end has been updated.
But I was not doing that earlier this year so what has changed in
these recent versions. Actually what should I be doing nowadays to
push back to the original 'master' branch?

Mads Kiilerich

unread,
May 2, 2011, 6:26:14 PM5/2/11
to hg-...@googlegroups.com, lsces
lsces wrote, On 05/02/2011 11:58 PM:
> On May 2, 10:32 pm, Mads Kiilerich<m...@kiilerich.com> wrote:
>> Did you put a bookmark on the heads you pushed? git and github requires
>> that.
> Well the repo had been cloned from github, and the updates sorted
> locally, so the 'master' bookmark was still in place, but 'moving' it
> seems to have unjammed things, and the github end has been updated.
> But I was not doing that earlier this year so what has changed in
> these recent versions.

Mercurial bookmarks usually do the right thing when I do the right
thing, so usually it just works - and that might also explain why it
worked for you last time you tried.

hg-git can't hide completely that there is a git behind it, so in some
cases you must know a bit about how git works so you can work around it.

/Mads

Brian Panulla

unread,
May 2, 2011, 11:01:56 AM5/2/11
to hg-...@googlegroups.com
I had a similar problem to this, and it had something to do with my Bookmarks. If I remember it correctly my "master" bookmark was not tracking the latest changeset, so when I would push it would be pushing three or four changesets back of the tip, which was already on GitHub. It had previously worked without intervention, so I suspect something changed in Mercurial.

I manually moved my master bookmark to the tip changeset and I added this to my .hgrc

[bookmarks]
track.current = True

Everything seems to be working now, but I'm not 100% sure this was precisely the problem. If you look at your Mercurial log, what revision shows as "master"?

-B

lsces

unread,
May 3, 2011, 9:13:19 AM5/3/11
to hg-git
On May 2, 4:01 pm, Brian Panulla <bpanu...@gmail.com> wrote:
> I manually moved my master bookmark to the tip changeset and I added this to
> my .hgrc
>
> [bookmarks]
> track.current = True
>
> Everything seems to be working now, but I'm not 100% sure this was precisely
> the problem. If you look at your Mercurial log, what revision shows as
> "master"?

That sorts the problem, and of cause 'bookmarks' is now integral to
Mercurial, so it's default settings have obviously changed?
TA ...

But I have found another piece of the jigsaw which I'll raise a
separate thread for ... the 'super-project' stuff is not playing
nicely together.

Kevin Bullock

unread,
May 3, 2011, 10:41:40 AM5/3/11
to hg-...@googlegroups.com
On May 2, 2011, at 10:01 AM, Brian Panulla wrote:

> I had a similar problem to this, and it had something to do with my Bookmarks. If I remember it correctly my "master" bookmark was not tracking the latest changeset, so when I would push it would be pushing three or four changesets back of the tip, which was already on GitHub. It had previously worked without intervention, so I suspect something changed in Mercurial.
>
> I manually moved my master bookmark to the tip changeset and I added this to my .hgrc
>
> [bookmarks]
> track.current = True

As of Mercurial 1.8, bookmarks are in core and there is no longer a track.current setting (the current bookmark _always_ tracks with your commits, i.e. the setting is always true).

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock

Lester Caine

unread,
May 3, 2011, 3:35:15 PM5/3/11
to hg-...@googlegroups.com
Kevin Bullock wrote:
> As of Mercurial 1.8, bookmarks are in core and there is no longer a track.current setting (the current bookmark_always_ tracks with your commits, i.e. the setting is always true).

In that case it is not working then, so we probably need to move this to the
main support list?

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

Abderrahim KITOUNI

unread,
May 3, 2011, 3:52:45 PM5/3/11
to hg-...@googlegroups.com
Hello;

2011/5/2 lsces <les...@lsces.co.uk>:

I think you need to update to the branch you're going to work on, even
if it is checked out by default as part of the clone, since at clone
time, hg update to default and not to master (or whatever branch
happens to be 'tipmost').

What changed is probably the fact that bookmarks.track.current is no
longer a setting (and is on by default), and as such if you don't
explicitly update to the bookmark (e.g. by updating to a revision
number), it won't track your commits.

It would be nice if someone tried to make hg update to master instead
of default when cloning from git.

HTH,
Abderrahim

Reply all
Reply to author
Forward
0 new messages