abort: push creates new remote heads!
Martin Geisler
mg at daimi.au.dk
Thu Apr 17 21:32:21 UTC 2008
"Joseph Turian" <turian at gmail.com> writes:
> Help! I am using mercurial to do development with several other
> persons. I didn't early enough, and now my repository is in a state
> from which I am not sure how to recover:
>
> ==========
>
> turian at grenat:~/dev/theano 1$ hg push
> pushing to ssh://[...]
> searching for changes
> abort: push creates new remote heads!
> (did you forget to merge? use push -f to force)
> turian at grenat:~/dev/theano 1$ hg pull
> pulling from ssh://[...]
> searching for changes
> adding changesets
> adding manifests
> adding file changes
> added 1 changesets with 1 changes to 1 files (+1 heads)
> (run 'hg heads' to see heads, 'hg merge' to merge)
> turian at grenat:~/dev/theano 1$ hg update
> abort: crosses branches (use 'hg merge' or 'hg update -C' to discard
> changes)
> turian at grenat:~/dev/theano 1$ hg merge
> abort: outstanding uncommitted changes
>
> ==========
>
> At this point, I am not sure what I should do. What is the correct way
> to get my repository back in a clean state?
The above message means that you changed your working copy but have not
yet committed it. The following sequence of commands will create this
situation:
% hg init repo
% cd repo
% echo foo > a.txt
% hg add
adding a.txt
% hg commit -m 1
So far so good, one revision was made.
% cd ..
% hg clone repo clone
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
The repository was cloned.
% cd repo
% echo bar >> a.txt
% hg commit -m 2
More work was done on repo.
% cd ../clone
% echo baz > b.txt
% hg add
adding b.txt
% hg commit -m 3
Work done and committed on clone.
% echo quux >> b.txt
% hg glog
@ changeset: 1:afcbeeb30383
| tag: tip
| user: Martin Geisler <mg at daimi.au.dk>
| date: Thu Apr 17 23:19:19 2008 +0200
| summary: 3
|
o changeset: 0:02fd557d2d2b
user: Martin Geisler <mg at daimi.au.dk>
date: Thu Apr 17 23:19:18 2008 +0200
summary: 1
% hg id
afcbeeb30383+ tip
More work on clone, but not yet committed. Notice how the 'hg id'
command tells us that we are at changeset afcbeeb30383, but with local
modifications (indicated by the '+').
% hg pull
pulling from /backup/mg/tmp/repo
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
% hg merge
abort: outstanding uncommitted changes
This is what you tried and it fails since the working copy has not yet
been committed. We can examine the situation with the glog command (from
the Graph log extension):
% hg glog
o changeset: 2:b3536c1a633e
| tag: tip
| parent: 0:02fd557d2d2b
| user: Martin Geisler <mg at daimi.au.dk>
| date: Thu Apr 17 23:19:18 2008 +0200
| summary: 2
|
| @ changeset: 1:afcbeeb30383
|/ user: Martin Geisler <mg at daimi.au.dk>
| date: Thu Apr 17 23:19:19 2008 +0200
| summary: 3
|
o changeset: 0:02fd557d2d2b
user: Martin Geisler <mg at daimi.au.dk>
date: Thu Apr 17 23:19:18 2008 +0200
summary: 1
% hg id
afcbeeb30383+
We are (still) on the afcbeeb30383 changeset with the local
modification. Merging this would be dangerous since there would be no
way for you to undo the merge if it turns out to be more difficult than
you thought.
The solution is simply to finish your changes in the clone and commit
them. This will create a child revision to the afcbeeb30383 revision:
% hg commit -m 4
% hg glog
@ changeset: 3:e71851fd7ea5
| tag: tip
| parent: 1:afcbeeb30383
| user: Martin Geisler <mg at daimi.au.dk>
| date: Thu Apr 17 23:25:34 2008 +0200
| summary: 4
|
| o changeset: 2:b3536c1a633e
| | parent: 0:02fd557d2d2b
| | user: Martin Geisler <mg at daimi.au.dk>
| | date: Thu Apr 17 23:19:18 2008 +0200
| | summary: 2
| |
o | changeset: 1:afcbeeb30383
|/ user: Martin Geisler <mg at daimi.au.dk>
| date: Thu Apr 17 23:19:19 2008 +0200
| summary: 3
|
o changeset: 0:02fd557d2d2b
user: Martin Geisler <mg at daimi.au.dk>
date: Thu Apr 17 23:19:18 2008 +0200
summary: 1
You can merge like normal:
% hg merge
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
% hg commit -m 'Merged.'
% hg glog
@ changeset: 4:78a5a3fed121
|\ tag: tip
| | parent: 3:e71851fd7ea5
| | parent: 2:b3536c1a633e
| | user: Martin Geisler <mg at daimi.au.dk>
| | date: Thu Apr 17 23:27:45 2008 +0200
| | summary: Merged.
| |
| o changeset: 3:e71851fd7ea5
| | parent: 1:afcbeeb30383
| | user: Martin Geisler <mg at daimi.au.dk>
| | date: Thu Apr 17 23:25:34 2008 +0200
| | summary: 4
| |
o | changeset: 2:b3536c1a633e
| | parent: 0:02fd557d2d2b
| | user: Martin Geisler <mg at daimi.au.dk>
| | date: Thu Apr 17 23:19:18 2008 +0200
| | summary: 2
| |
| o changeset: 1:afcbeeb30383
|/ user: Martin Geisler <mg at daimi.au.dk>
| date: Thu Apr 17 23:19:19 2008 +0200
| summary: 3
|
o changeset: 0:02fd557d2d2b
user: Martin Geisler <mg at daimi.au.dk>
date: Thu Apr 17 23:19:18 2008 +0200
summary: 1
This is the general rule of thumb when using Mercurial: finish your work
and commit it before you start pulling in stuff from the outside world.
--
Martin Geisler
VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multi-Party Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20080417/51bc171f/attachment-0001.asc>
More information about the Mercurial
mailing list