Discussion:
Help. I've screwed up my repo again, and I have no idea how.
(too old to reply)
Rob Landley
2006-11-02 02:30:54 UTC
Permalink
When I say "hg diff Makefile" mercurial refuses to see any differences between
the version in my repository and the last checked in version. If I say "hg
diff -r 7 Makefile" it shows differences between that version and the last
checked in version, again totally ignoring what's in my actual working
directory.

When I go "hg diff" it shows nothing. When I go "hg status" it shows every
file in the entire tree.

What the heck is going on?

A copy of my screwed up repository is at:
http://landley.net/code/toybox/toybox3.tbz

Notice: Makefile doesn't match the last checkin but try getting hg to
acknowledge that, and whatever new changes I make I simply cannot force hg to
notice them.

What did I do? How do I undo it? How do I prevent it from happening again,
since this isn't the first time I've done whatever this is and had to restore
from a backup. (Those of you whose email archives go back farther than the
web page's, check my message on october 8...)

I also tried updating mercurial to the current development version, but that
made no difference.

Help?

Rob
--
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery
Rob Landley
2006-11-02 03:00:39 UTC
Permalink
Post by Rob Landley
What the heck is going on?
http://landley.net/code/toybox/toybox3.tbz
Looking at that, I see that "hg manifest" shows the new files I added
yesterday, but none of the files from before that. If I do "hg manifest 9"
it shows the previous files, but "hg manifest 10" shows _only_ the new files,
it's lost track of all the old ones.

Question: why does diff need -r to specify a revision, but manifest doesn't
understand -r?

It's like the sucker things it has two heads, despite the fact I never told it
to branch (I don't think I did, anyway). "hg heads"... Yup, somehow it
seems to have acquired two heads when I added files last night. Ok, "hg
update" and "hg merge" and... It says the files conflict. Well of COURSE,
I've been doing work in the darn repository. Take the new ones already!

Right, mv Makefile Makefile.bak, hg revert Makefile... And it's not in the
current changeset. Well go back and FIND it you stupid... Sigh. "hg
revert -r 9 Makefile", now:

$ hg merge
abort: outstanding uncommitted changes
$ hg commit
Please choose a commit username to be recorded in the changelog via
command line option (-u "First Last <***@example.com>"), in the
configuration files (hgrc), or by setting the EMAIL environment variable.

abort: No commit username specified!
transaction abort!
rollback completed

I've been using this darn thing for WEEKS without whatever this problem is.
My fault upgrading to try to make what looked like a bug go away. Ok,
whereis hgrc, finds a man page, says I should edit /etc/mercurial/hgrc which
is essentially empty, read the man page some more...

Question: Why doesn't the error message above say _HOW_ to add a commit
username to hgrc? It's not obvious. Read far enough in the man page and you
find it's key "username" in section "ui", except that says the default is
***@hostname which is apparently no longer the case.

Sigh. I wanted to spend tonight working on my project (toybox). Instead I
spend it fighting Mercurial.

Rob
--
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery
Rob Landley
2006-11-02 03:33:53 UTC
Permalink
Post by Rob Landley
Sigh. I wanted to spend tonight working on my project (toybox). Instead I
spend it fighting Mercurial.
One little thing about the tutorial:

http://www.selenic.com/mercurial/wiki/index.cgi/TutorialConflict

If you don't notice you've accidentally split your repository into two heads
(and still have now idea how it happened), and you're trying to merge the
result, if your working directory already has a copy of the file that doesn't
match either head, mercurial won't bring up a merge tool, it'll balk with no
real explanation.

What you have to do is move your updated copies of every file somewhere else
(and it'll only complain about them one at a time, so get used to typing "hg
merge" repeatedly), and then when you're done and you do an hg commit with a
message about putting the two captain kirks back together in the transporter,
then move all your .bak files back to where they go and _now_ you can check
them in.

This was not obvious. I still want to know how I accidentally created a new
head, how to tell that I've done it without explicitly checking for it, and
how to avoid doing it again without meaning to.

Rob
--
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery
Brendan Cully
2006-11-02 04:43:19 UTC
Permalink
I really don't know how you got your repository into the state it was
in (revisions 10 and 11 are not just branches, they are completely
unrelated to the rest of your repo), but there is a simpler way to
fix it:

hg clone toybox tmp
cd tmp
hg merge
hg commit -m'merge'
hg pull ../tmp
cp ../tmp/.hg/dirstate .hg
rm -r ../tmp

copying the dirstate is a little grody, but should work.
Post by Rob Landley
Post by Rob Landley
Sigh. I wanted to spend tonight working on my project (toybox).
Instead I
spend it fighting Mercurial.
http://www.selenic.com/mercurial/wiki/index.cgi/TutorialConflict
If you don't notice you've accidentally split your repository into two heads
(and still have now idea how it happened), and you're trying to merge the
result, if your working directory already has a copy of the file that doesn't
match either head, mercurial won't bring up a merge tool, it'll balk with no
real explanation.
What you have to do is move your updated copies of every file
somewhere else
(and it'll only complain about them one at a time, so get used to typing "hg
merge" repeatedly), and then when you're done and you do an hg
commit with a
message about putting the two captain kirks back together in the transporter,
then move all your .bak files back to where they go and _now_ you can check
them in.
This was not obvious. I still want to know how I accidentally
created a new
head, how to tell that I've done it without explicitly checking for it, and
how to avoid doing it again without meaning to.
Rob
--
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-
Exupery
_______________________________________________
Mercurial mailing list
http://selenic.com/mailman/listinfo/mercurial
Rob Landley
2006-11-02 06:04:40 UTC
Permalink
Post by Brendan Cully
I really don't know how you got your repository into the state it was
in (revisions 10 and 11 are not just branches, they are completely
unrelated to the rest of your repo),
The frightening part is this isn't the first time I've done that. The
previous times, I just backed up to a saved tarball of the entire directory.
Post by Brendan Cully
but there is a simpler way to
hg clone toybox tmp
cd tmp
hg merge
hg commit -m'merge'
I understand up to that point. I suspect that right here there's a
missing "cd ../toybox"? Otherwise the ../tmp when we're in tmp is black
magic...
Post by Brendan Cully
hg pull ../tmp
cp ../tmp/.hg/dirstate .hg
rm -r ../tmp
copying the dirstate is a little grody, but should work.
What's in dirstate, anyway?

One thing I've noticed in another repository I have lying around
is .hg/dirstate is owned by root (none of the other files are). Apparently I
did some hg thing while logged in as root, without noticing. This means that
on the next update as my normal user, it can't write to that file, but maybe
it doesn't notice that it can't?

Did I mention I have a knack for breaking stuff?

Rob
--
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery
Brendan Cully
2006-11-02 07:18:14 UTC
Permalink
Post by Rob Landley
Post by Brendan Cully
I really don't know how you got your repository into the state it was
in (revisions 10 and 11 are not just branches, they are completely
unrelated to the rest of your repo),
The frightening part is this isn't the first time I've done that. The
previous times, I just backed up to a saved tarball of the entire directory.
Post by Brendan Cully
but there is a simpler way to
hg clone toybox tmp
cd tmp
hg merge
hg commit -m'merge'
I understand up to that point. I suspect that right here there's a
missing "cd ../toybox"? Otherwise the ../tmp when we're in tmp is black
magic...
you're right, I forgot a cd ../toybox.
Post by Rob Landley
Post by Brendan Cully
hg pull ../tmp
cp ../tmp/.hg/dirstate .hg
rm -r ../tmp
copying the dirstate is a little grody, but should work.
What's in dirstate, anyway?
Pointers to the parents (revision you've checked out, plus a merge
revision if you're doing one), and a stat cache for quickly computing
status. hg debugsetparents tip; hg debugrebuildstate would have
accomplished the same thing.
Post by Rob Landley
One thing I've noticed in another repository I have lying around
is .hg/dirstate is owned by root (none of the other files are).
Apparently I
did some hg thing while logged in as root, without noticing. This means that
on the next update as my normal user, it can't write to that file, but maybe
it doesn't notice that it can't?
Did I mention I have a knack for breaking stuff?
That does sound like a likely culprit.
Matt Mackall
2006-11-02 06:08:34 UTC
Permalink
Post by Rob Landley
Post by Rob Landley
What the heck is going on?
http://landley.net/code/toybox/toybox3.tbz
Looking at that, I see that "hg manifest" shows the new files I added
yesterday, but none of the files from before that. If I do "hg manifest 9"
it shows the previous files, but "hg manifest 10" shows _only_ the new files,
it's lost track of all the old ones.
Question: why does diff need -r to specify a revision, but manifest doesn't
understand -r?
Good question. Manifest was originally a debugging command. It ought
not show those ugly hashes by default too.
Post by Rob Landley
It's like the sucker things it has two heads, despite the fact I never told it
to branch (I don't think I did, anyway). "hg heads"... Yup, somehow it
seems to have acquired two heads when I added files last night. Ok, "hg
update" and "hg merge" and... It says the files conflict. Well of COURSE,
I've been doing work in the darn repository. Take the new ones already!
$ hg merge
abort: 'Makefile' already exists in the working dir and differs from
remote

This message could be more specific. The trouble here is that Makefile
is unknown, on this branch at least. Proceeding is likely to destroy
data. Fixed.
Post by Rob Landley
Right, mv Makefile Makefile.bak, hg revert Makefile... And it's not in the
current changeset. Well go back and FIND it you stupid...
It's never existed on this branch so there's no back to go to.
Post by Rob Landley
Sigh. "hg
Your history looks like this:

11 9
\ /
10 0-1-2-3-4-5-6-7-8
\ /
empty

So at some point, you started committing in a repo you'd never done a
checkout in. Or you deleted your .hg/dirstate file. Any idea how that
happened?

You've actually found a bug here, by the way:

changeset: 10:4d21d59f3206
user: ***@driftwood
date: Tue Oct 31 23:30:06 2006 -0500
summary: Add menuconfig, plus some basic Config info, lots of

We don't report that the parent is not 9.
Post by Rob Landley
$ hg merge
abort: outstanding uncommitted changes
Again, we don't like to merge here because merging is potentially
destructive. Forcing a commit allows botched merges to be redone. And
it also makes the history more detailed, differentiating changes done
before and during the merge.
Post by Rob Landley
$ hg commit
Please choose a commit username to be recorded in the changelog via
configuration files (hgrc), or by setting the EMAIL environment variable.
abort: No commit username specified!
transaction abort!
rollback completed
I've been using this darn thing for WEEKS without whatever this problem is.
My fault upgrading to try to make what looked like a bug go away. Ok,
whereis hgrc, finds a man page, says I should edit /etc/mercurial/hgrc which
is essentially empty, read the man page some more...
Note that the recorded username is ***@driftwood. Not very useful
for an actual distributed project. Rather than clutter project
histories with guesses, we're now making people set a name.

This should be in the readme.
Post by Rob Landley
Question: Why doesn't the error message above say _HOW_ to add a commit
username to hgrc? It's not obvious. Read far enough in the man page and you
find it's key "username" in section "ui", except that says the default is
Because some clever person decided my original terse message was not
verbose enough. Also, you have an old manpage in your path.
--
Mathematics is the supreme nostalgia of our time.
Rob Landley
2006-11-02 08:13:52 UTC
Permalink
Post by Matt Mackall
So at some point, you started committing in a repo you'd never done a
checkout in. Or you deleted your .hg/dirstate file. Any idea how that
happened?
I think dirstate got screwed up. It's possible I deleted the wrong file in a
sleep deprived state while trying to undo an add. (What's the correct way to
go "wait, calling 'hg add' without an argument was not what I meant to do,
but I haven't committed it yet, so how do I make the pending uncommitted adds
go away?" My memory is that hg help was unrevealing on this subject.). It's
also possible I did a repository action as root that accidentally made the
sucker read only for my normal user, and it later got confused by this.
Heck, knowing me I could have done both...
Post by Matt Mackall
changeset: 10:4d21d59f3206
date: Tue Oct 31 23:30:06 2006 -0500
summary: Add menuconfig, plus some basic Config info, lots of
We don't report that the parent is not 9.
Post by Rob Landley
$ hg merge
abort: outstanding uncommitted changes
Again, we don't like to merge here because merging is potentially
destructive. Forcing a commit allows botched merges to be redone. And
it also makes the history more detailed, differentiating changes done
before and during the merge.
Understood.

I eventually got the repository untangled. I plan to write up additional
documentation once I have a better idea about what I'm doing. (I write
documentation out of sheer self-defense...)
Yup, me at my laptop.
Post by Matt Mackall
for an actual distributed project. Rather than clutter project
histories with guesses, we're now making people set a name.
I figured it was the upgrade that did it, and it's a reasonable thing to do.
I was just a bit frustrated by that point. :)
Post by Matt Mackall
This should be in the readme.
Post by Rob Landley
Question: Why doesn't the error message above say _HOW_ to add a commit
username to hgrc? It's not obvious. Read far enough in the man page and you
find it's key "username" in section "ui", except that says the default is
Because some clever person decided my original terse message was not
verbose enough. Also, you have an old manpage in your path.
I did an hg pull, make all, make install. (I think that's what I did.)
That's the only man page I've got.

I figured it out from the man page eventually, and later I bumped into a
section of the tutorial said how to add it too. Since that seems to be the
only part of hgrc you actually _need_, it might be nice if it was a little
more prominent in the man page.

Thanks for your help. It's a very nice project I hope to actually use
competently someday. :)

Rob
--
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery
Thomas Arendsen Hein
2006-11-02 11:39:47 UTC
Permalink
Post by Matt Mackall
11 9
\ /
10 0-1-2-3-4-5-6-7-8
\ /
empty
changeset: 10:4d21d59f3206
date: Tue Oct 31 23:30:06 2006 -0500
summary: Add menuconfig, plus some basic Config info, lots of
We don't report that the parent is not 9.
Known problem, just waiting for a comment:
http://www.selenic.com/mercurial/bts/issue385
Post by Matt Mackall
Post by Rob Landley
$ hg commit
Please choose a commit username to be recorded in the changelog via
configuration files (hgrc), or by setting the EMAIL environment variable.
Question: Why doesn't the error message above say _HOW_ to add a commit
username to hgrc? It's not obvious. Read far enough in the man page and you
find it's key "username" in section "ui", except that says the default is
Because some clever person decided my original terse message was not
verbose enough.
Being the clever person reacting to wishes of other users here I'd
like to clarify the current situation: "Please specify a username."
is indeed nice and short (one line), but probably not very helpful.

The I-want-to-commit-now-no-time-to-read-docs user gains all
information about what to do: -u "First Last <***@example.com>"
(two lines)

The But-always-using-that-option-is-stupid-user gets a hint that
there is something else he can look for to make this more permanent.
(three lines)

Of course there can be a long page explaining everything about
usernames etc., but an error message is not the right place.
What I want is the next generation help system in which you can do:

$ hg commit
Abort: Please specify a username. (see 'hg help username')
$ hg help username
Explain everything about username

See http://www.selenic.com/mercurial/bts/issue197

Thomas
--
Email: ***@intevation.de
http://intevation.de/~thomas/
Samuel Tardieu
2006-11-02 15:09:59 UTC
Permalink
Thomas> $ hg commit
Thomas> Abort: Please specify a username. (see 'hg help username')

I like it, but I think this may turn some people off from using
Mercurial (some users are already afraid of using versioning systems).

What could be done instead is *ask* the user to provide a username,
such as in

% hg commit
Please configure your full name and email address:
Full name [default: Samuel Tardieu]: <wait for user input>
Email address [default: ***@rfc1149.net]: <wait for user input>

and update ~/.hgrc appropriately.

The default, on Unix, could be derived from gecos, login and
/etc/mailname, domainname or hostname.

Sam
--
Samuel Tardieu -- ***@rfc1149.net -- http://www.rfc1149.net/
Thomas Arendsen Hein
2006-11-02 16:40:21 UTC
Permalink
Post by Samuel Tardieu
Thomas> $ hg commit
Thomas> Abort: Please specify a username. (see 'hg help username')
I like it, but I think this may turn some people off from using
Mercurial (some users are already afraid of using versioning systems).
What could be done instead is *ask* the user to provide a username,
such as in
% hg commit
Full name [default: Samuel Tardieu]: <wait for user input>
and update ~/.hgrc appropriately.
What should happen if you already have a ~/.hgrc which just doesn't
set username? How verbose has the message to be explaining what
happens now that you put in personal data here?

I think it is important that Mercurial doesn't start to do things
magically, this might annoy the experienced user and confuse the
beginner.

Unlike e.g. codeville we don't have a command to store some
variables like username. If we had, you could just say:
$ hg commit
Abort: No username set, please use something like:
hg setconfig ui.username="foo <***@example.com>"

People using the commit feature of versioning systems should be able
to use an editor I think. Or do I make wrong assumtions here?

Thomas
--
Email: ***@intevation.de
http://intevation.de/~thomas/
Rafael Villar Burke
2006-11-02 17:00:00 UTC
Permalink
Post by Thomas Arendsen Hein
I think it is important that Mercurial doesn't start to do things
magically, this might annoy the experienced user and confuse the
beginner.
Maybe it would be useful having a helper setup script that is able to
build up an hgrc file for you by answering some simple questions, such
as name, address, favourite editor route, favourite diff and merge tool
or verbosity level. That way the magic could go away from the core
application and the installation and initial steps would be easier.
Later, you can tweak the hgrc by hand or could use that script to save
to a different file.
Probably this could be a nice way to contribute for someone that thinks
this would be nice to have :).

Regards,

--
Rafael Villar Burke
www.rvburke.com
Joseph Bruce
2006-11-02 18:05:34 UTC
Permalink
Post by Rafael Villar Burke
Post by Thomas Arendsen Hein
I think it is important that Mercurial doesn't start to do things
magically, this might annoy the experienced user and confuse the
beginner.
Maybe it would be useful having a helper setup script that is able to
build up an hgrc file for you by answering some simple questions, such
as name, address, favourite editor route, favourite diff and merge tool
or verbosity level. That way the magic could go away from the core
application and the installation and initial steps would be easier.
Later, you can tweak the hgrc by hand or could use that script to save
to a different file.
That's an excellent idea. At this point I am experienced enough with
Mercurial that I just copy my .hgrc and .hgignore around from machine to
machine as my use of hg propagates (e.g., to personal projects where
previously I used svn). For a novice who doesn't like to read the
documentation / do the tutorial, a setup script would be a useful
contribution.

Probably this could be a nice way to contribute for someone that thinks
Post by Rafael Villar Burke
this would be nice to have :).
Agreed! NOTE: I am not volunteering to write one -- I just think it'd be
helpful. If only I had more free time...

- Joe
Mathieu Clabaut
2006-11-02 17:03:41 UTC
Permalink
Post by Thomas Arendsen Hein
People using the commit feature of versioning systems should be able
to use an editor I think. Or do I make wrong assumtions here?
Of course you're right.
But I must say that a feature that directed me to use mercurial was its "at
once ready advertisement" (just do an "hg init" and voila.... No user, key
or certificate settings, no server settings, and so one).
So please, limit the required configuration to the strict minimum.
-mathieu
Thomas Arendsen Hein
2006-11-02 20:40:05 UTC
Permalink
Post by Mathieu Clabaut
Post by Thomas Arendsen Hein
People using the commit feature of versioning systems should be able
to use an editor I think. Or do I make wrong assumtions here?
Of course you're right.
But I must say that a feature that directed me to use mercurial was its "at
once ready advertisement" (just do an "hg init" and voila.... No user, key
or certificate settings, no server settings, and so one).
Hrm, you're absolutely right ...

+1 for asking one question (ui.username) when it is needed the first
time and no ~/.hgrc exists yet, but still bail out if it does.

Thomas
--
Email: ***@intevation.de
http://intevation.de/~thomas/
TK Soh
2006-11-02 21:27:52 UTC
Permalink
Post by Thomas Arendsen Hein
Unlike e.g. codeville we don't have a command to store some
$ hg commit
Or can we just ask user to use the -u option in the message. I guess
some users may not want to have to deal the config right away.
Especially for new users that simply want to 'try things out'.
Post by Thomas Arendsen Hein
People using the commit feature of versioning systems should be able
to use an editor I think. Or do I make wrong assumtions here?
Probably not a very safe assumption.
Mathieu Lacage
2006-11-03 12:42:05 UTC
Permalink
Post by Thomas Arendsen Hein
Post by Samuel Tardieu
Thomas> $ hg commit
Thomas> Abort: Please specify a username. (see 'hg help username')
I like it, but I think this may turn some people off from using
Mercurial (some users are already afraid of using versioning systems).
What could be done instead is *ask* the user to provide a username,
such as in
% hg commit
Full name [default: Samuel Tardieu]: <wait for user input>
and update ~/.hgrc appropriately.
What should happen if you already have a ~/.hgrc which just doesn't
set username? How verbose has the message to be explaining what
happens now that you put in personal data here?
I think it is important that Mercurial doesn't start to do things
magically, this might annoy the experienced user and confuse the
beginner.
Unlike e.g. codeville we don't have a command to store some
$ hg commit
People using the commit feature of versioning systems should be able
to use an editor I think. Or do I make wrong assumtions here?
You are right but this sort of thing is just really handy. For example,
darcs always records the equivalent of default-push in the repository
upon the first push if there is none. And this does save the user a bit
of effort. I consider myself a not-too-smart user and this sort of thing
just saves time. I don't think it hampers the predictability of
mercurial behavior either.

I think that a repository-specific hgrc file which can be automagically
edited by mercurial would be quite useful in that it would decrease the
barrier to start using mercurial.

Mathieu
--

Continue reading on narkive:
Loading...