abort: push creates new remote heads!
Joseph Turian
turian at gmail.com
Fri Apr 18 18:28:25 UTC 2008
By the way, what is the difference between '@' and 'o' in the glog?
I didn't see a description in the documentation.
Best,
Joseph
On Fri, Apr 18, 2008 at 2:15 PM, Joseph Turian <turian at gmail.com> wrote:
> Martin,
>
> Thanks for the update! This was a very clear explanation for me.
>
> Joseph
>
> On Thu, Apr 17, 2008 at 5:32 PM, Martin Geisler <mg at daimi.au.dk> wrote:
>
> > "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/.
> >
> > _______________________________________________
> > Mercurial mailing list
> > Mercurial at selenic.com
> > http://selenic.com/mailman/listinfo/mercurial
> >
> >
>
>
> --
> Academic: http://www-etud.iro.umontreal.ca/~turian/<http://www-etud.iro.umontreal.ca/%7Eturian/>
> Business: http://www.metaoptimize.com/
>
--
Academic: http://www-etud.iro.umontreal.ca/~turian/
Business: http://www.metaoptimize.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20080418/d54cb286/attachment-0001.html>
More information about the Mercurial
mailing list