I have a hg respository located in a ~/Server folder on my computer. when I run hg summary from the root of that project, I get the following:
parent: 98:408483c17026 tip
final proposal page set up
branch: GS_Clients
commit: 6 deleted (clean)
update: (current)
So I wanted to make a backup copy of this project in my dropbox folder, so I ran :
hg clone <current_source> ~/Dropbox/Repositories/<new_source>
yet when I run hg summary in the new directory, is states that it is at revision 0:
parent: 0:b03c2c025c61
inital commit
branch: default
commit: (clean)
update: (current)
I've tried all manners of pushing,pulling and updating, but I can't get the new repo up to date.
How can I make a clone that is up to date, and/or how can I get this repo up to date.
Your first summary is on branch GS_Clients, while the second one, because it is a fresh clone, is on the default branch. Try hg update GS_Clients.
The update: (current) line only means you're at a head of the current branch.
I figure only rev 0 is on the default branch, and all your other commits are on GS_Clients or other named branches. Commands like log, glog, and UIs like TortoiseHg would have made that pretty obvious, where summary does not.
Related
I am using hg convert to convert a Git repo into Mercurial on a Mac running macOS Mojave.
I've looked at similar questions How to use hg convert properly and hg convert not actually converting? but they haven't provided a definitive answer.
The command I've entered is:
hg convert ./my-src-dir/ my-dest-dir
The output is as follows:
initializing destination my-dest-dir repository
scanning source...
sorting...
converting...
6918 commit comment.
6917 commit comment.
6916 commit comment.
6915 commit comment.
6914 commit comment.
6913 commit comment.
This continues until the most recent commit...
1 commit comment.
0 commit comment.
updating bookmarks
I'm new to Mercurial. I can't see any errors but the destination directory only contains a .hg folder.
The output of hg sum is:
parent: -1:000000000000 (no revision checked out)
branch: default
commit: (clean)
update: 6919 new changesets (update)
phases: 6919 draft
Am I using this command correctly? I'm expecting to see all my src files in the new folder.
The key is:
parent: -1:000000000000 (no revision checked out)
The conversion presumably did work but you haven't yet updated your working folder to any particular changeset. So it appears to be empty.
Not knowing what (if any) branches, bookmarks, etc. are in the repo I can't say exactly what you should update to. But let's say you just want the last revision in there, you could do:
$ cd my-dest-dir
$ hg up tip
to get to whatever it thinks the last one is.
I run the following hg command and see a whole bunch of revision numbers & their messages fly past my screen, but when it finishes the destination hg repository is empty.
hg convert -s p4 //depot/proj1/... c:\hg\proj1 --config convert.p4.startrev=1267
What am I doing wrong?
When in doubt, use the summary command. You'll probably see something like this:
$ hg sum
parent: -1:000000000000 (no revision checked out)
branch: default
commit: (clean)
update: 15225 new changesets (update)
This says "nothing checked out, on the default branch, nothing to commit, 15225 changesets if you update".
An empty repo looks like this:
$ hg sum
parent: -1:000000000000 tip (empty repository)
branch: default
commit: (clean)
update: (current)
The repository is not empty. There should be an empty directory, .hg, which contains the whole history of your project.
If you want to see the state of your repo at the latest revision, you can update your local copy with hg update.
It turned out my Perforce database had a bit of corruption in very early changesets. Once I told the convert extension to start at a later change set, the conversion went without a hitch.
I'm new to Mercurial, and I made the mistake of making different changes on different systems before the main repository was up to date. (I understand this is what Mercurial is built for, but my thick brain is struggling to resolve the issue.)
Now on my primary development server, everything is up to date and committed. However...
$ hg push
abort: push creates new remote branches: 4f2672f039d7!
(use 'hg push --new-branch' to create new remote branches)
I don't really want a new branch. I just want all the changes to be merged.
$ hg heads
changeset: 459:ff5f94e44aba
branch: 4f2672f039d7
tag: tip
parent: 458:e63d02baf4cf
parent: 455:267abda62069
user: mike#...
date: Tue Sep 13 14:25:16 2011 -0400
summary: Images from prof
changeset: 455:267abda62069
parent: 453:a74757e26357
user: mike#localhost.localdomain
date: Tue Sep 13 09:08:12 2011 -0400
summary: images for FLC
Point me in the right direction?
EDIT: (adding detail)
When I try to merge, I get the following result:
$ hg merge
abort: branch '4f2672f039d7' has one head - please merge with an explicit rev
(run 'hg heads' to see all heads)
I have tried hg merge ff5f94e44aba, and all of the revs listed above, and each one returns the same result:
$ hg merge 267abda62069
abort: merging with a working directory ancestor has no effect
It looks like you've accidentally created a branch with a silly name. What you most likely want to do is reapply your changes with a branch name that makes better sense. There's no totally automatic way of doing this, but you can extract each changeset as a patch, revert to the point where you messed up and reapply those changes on the proper branch.
Basically what you need to do is look at the changelog; probably by running hg out to see what's missing from the central repository. Make a note of each of the revs that you want to keep.
Next update to the last good revision. Make sure that you are on the branch you wanted your commits to be on.
Now you will apply each of the changes you made and commit each one. You can automate this process something like this:
BADREVS="123 124 125 126"
recommit() { hg di -c $1 | patch -p1; hg ci -m "$(hg log -r $1 --template '{desc}')";}
for rev in $BADREVS; do
recommit $rev
done
Now you've got your changes in your local repository twice; once as the commits on the weird branch and again on the right branch. You can push those changes to the central repo using hg push -b GOODBRANCH so that only the changes to the right branch go up; Alternatively, you can install the strip extension to remove the changes you didn't want from the local repo and then you can push as normal.
By the sound of it; you will still have to deal with the changes made to the central repository before you can push, since you pushed changes from another repo. You probably want to do this merging after you clean up the change history in the local repo.
Pull from remote and then update / merge / commit first. Then you won't make new branches.
I've had this happen when I missed a merge. I like the TortoiseHg workbench for this because it can be a little easier to find what you missed through visualization.
A good way to avoid this in the future, how I stopped getting this error, is the fetch extension. Set your post pull to fetch and it will automatically merge for you, which is very nice. If there's a conflict it brings up whatever conflict resolver you use.
If I create a new branch using hg:
$ hg branch newbranch
And then look at branches:
$ hg branches
default 194:d9df55198e53
newbranch 193:a36a491b8507 (inactive)
newbranch is marked as (inactive), despite my working directly being currently mapped to it.
If I do a commit, default will then be flagged (inactive).
However, if I switch to default, merge, and commit, then switch back to newbranch, newbranch will say (inactive) again.
This is a bit of a pain, because I may do that on a friday night, and not come back to it until Monday, and not know what branch my working directory is actually pointed at.
So, is there a better way to tell, or should I always make it my workflow to specify the branch I want to work in before I start.
Though hg summary will tell you what branch you're on, so will hg branch without a branch name argument. Let's say I've never created a branch called mybranch before, but I want to start it:
> hg branch
default
> hg branch mybranch
marked working directory as branch mybranch
And now I've worked for a bit and want to commit, but forgot if I set the branch name for this next commit or not:
> hg branch
mybranch
Oh, I did.
Ok, I just discovered hg sum:
$ hg sum
parent: 195:d0a2617b4b51 tip
[Commit Message]
branch: newbranch
commit: (clean)
update: (current)
So I guess this is how you do it?
We're using a local central repository where everyone pushes to and pulls from. Until recently this repository only contained the .hg folder. Then someone went ahead and committed directly in the central repository creating an "island" changeset with no parent (parent = -1) nor child. The correct way would have been to add it in a local repository and push the changes.
Is there any way to get the working copy of the central repository to get back to the state where it only contain .hg and not be associated with a specific changeset?
The command:
hg update null
Updates a repository's working directory to the point before the first commit, so there are no files in the working directory and hg parents shows -1.
You'll still need to remove the commit if you don't want it, but that's a separate question/issue.
Since this is your local central repository and these are commands that edit history, please take every precaution, like trying things out on a copy of the repository first.
hg rollback (to remove the last repository change)
https://www.mercurial-scm.org/wiki/Rollback
Roll back the last transaction in a repository.
hg strip (to remove specific revisions)
https://www.mercurial-scm.org/wiki/Strip
hg strip rev removes the rev revision and all its descendants from a repository.
Also see:
https://www.mercurial-scm.org/wiki/EditingHistory
If you catch your mistake immediately (or reasonably soon), you can just use hg strip REV to roll back the latest (one or more) changes. ...
Edit: This answers the question in its original form. The OP has since edited the question.
Just delete everything except the .hg folder.
If I understand correctly what happened, someone changed into the repository directory and committed a single file as an 'added file' without first checking out any changeset from the active directory.
What you ended up with is something like the following history graph:
0:a43f 1:2843 2:bc81 3:2947
o ------ o ------ o ------ o
4:228f
o
where changeset 4:228f has the "null id" as its parent changeset.
Depending on whether you want to keep changeset 4:228f or not, you can follow one of the following strategies:
Option 1: Clone the repository without the offending change
You can create a new clone of the repository, specifying revision 3:2947 as the target revision. This will pull change 3:2947 and all its ancestor changesets into the new repository. Since the offending changeset is not linked into the ancestry of changeset 3:2947, it will not be part of the new clone.
I recommend saving the old repository first, and then moving everything over to a new clone, e.g. any repository-specific setup files you keep in its .hg/ directory.
If your current repository lives in /work/repo/foo, one way to do this would be:
$ cd /work/repo
$ mv foo foo.bak
$ hg clone -r 2947 foo.bak newfoo
Now copy over any .hg/ setup files, e.g. your original .hg/hgrc file:
$ cp foo.bak/.hg/hgrc newfoo/.hg/hgrc
Finally move the new foo repository in place:
$ mv newfoo foo
Option 2: Clone the repository and keep but rebase the change
Do the same as before, but before you move the newfoo repository in place, use the "hg export" command to extract a copy of the offending change from the old repository. Then check out a working copy of the tip-most changeset in the newfoo tree and import the file changes of the offending change as a normal changeset of your current history graph.
So, right before mv newfoo foo, save the patch of the offending change by typing:
$ cd /work/repo/foo.bak
$ hg export -r 228f --git > /tmp/patchfile.diff
then you can check-out the latest revision of the new repository, and re-import the patch on top of your current history:
$ cd /work/repo/newfoo
$ hg update --clean tip
$ hg import /tmp/patchfile.diff
If the offending changeset merely adds a new file, this should work fine and you are ready to move the new repository in place!
Before doing the final rename though, it may be a good idea to remove the working-copy files of the new repository:
$ cd /work/repo/newfoo
$ hg update --clean null