If you see here, you'll see that I have:
CheeryTomatoe.Examples <--- I want to remove this.
CherryTomatoe
CherryTomatoe.Examples
https://bitbucket.org/sergiotapia/cherrytomato
How can I completely remove this from my repository? What command can I run?
In theory, you can edit the history (provided nobody has yet cloned your public repo), as described in:
Mercurial FAQ 4.14 and 4.15
Mercurial Wiki "Editing the History"
However, that is not the best way to work with Mercurial, so what you did in your third commit is better: hg rename:
See Hg book: "renaming file":
When you use the hg rename command, Mercurial makes a copy of each source file, then deletes it and marks the file as removed.
It is your initial commit.
Delete the repository and start over.
Related
This is basically the same question as Temporarily switch working copy to a specific Git commit, but for Mercurial.
Say revision 500 is the last revision I've committed in Mercurial. I've worked some more, and realized something went wrong in an earlier revision. So, I've "git stashed", that is, hg shelved my current changes, so I am at a clean revision 500.
Now what I want to do is checkout revision 499, rebuild software, see if it still has error; if it does, checkout revision 498, rebuild software, see if it still has error; if it does, revision 497, rebuild software, see if it still has error; etc etc until I figure out which revision introduced the error.
Once I'm done with that, I want to go back to revision 500, unshelve my previous work, add to that a fix, and then make a new commit (which would be revision 501). That means when I go back in history I don't want to reset anything, nor stage anything from there.
In git I can just do git checkout HASH to go back in history, and once done, git checkout master to go back to the tip. Which commands should I use in Mercurial?
You can go to older revisions using hg update:
hg update 499 # The short id number or the full hash
or alternatively if you want to step to the parent changeset without needing to know the id, you can use a mercurial revset:
hg update .~1
once you have identified your issue you can simply:
hg update tip
and unshelve your changes, add your fix and commit.
I recommend you read the Mercurial: The Definitive Guide. Your question very basic / entry level mercurial usage.
Edit: the link to Mercurial: Definitive Guide is:
http://hgbook.red-bean.com/read/
or the 1.9 version of the boook:
https://book.mercurial-scm.org/read/index.html
I am using Mercurial Shelve extension to shelve changes from command line. It works nice except when the changes that i like to shelve contain new added files(a) in working directory. Basically, it shelves everything except the new added files. I checked this by looking at the .hg/shelve stored changes.
How to shelve new added files (a status)?
This response is overdue, but you can use the following command to shelve all files (track / untrack) :
hg shelve -A
or
hg shelve --addremove
About this command, documentation says :
mark new/missing files as added/removed before shelving
You must pay attention by using this feature because after unshelving, your old untracked files are track.
These file are already to be commited in the last commit if no files are specified in hg commit command. You should use hg forget if you want untracked them again.
I assume you are talking about currently untracked files? You need to add the first.
So just do hg add for your new files and then hg shelve will also shelve them.
Thank you Tom. I am using Mac, so it didn't really worked. What did work was another mercurial extension 'hgattic' about which you can read more in my blog
http://margotskapacs.com/2012/10/shelving-uncommitted-changes-in-mercurial/
(see section 'Bug – Added Files Unable Shelve')
If the command line isn't absolutely necessary:
then just type (on Linux)
thg shelve
This allows you to easily shelve added (but not yet committed) files.
As a mostly Git user, I find Atlassian SourceTree the easiest way to deal with the odd Mercurial repo that I have to work with. It has shelving built in. The price is right, too (free).
Disclaimer: I work for Atlassian
I have been happily using HgSubversion for awhile and today I forgot to add the --svn to the rebase command.
Now i get the dreaded unknown revision ''
Is there a way to recover from this?
You should be able to do "hg svn rebuildmeta" and then do "hg pull" and have it repair things.
Note: this is untested, so I'd work on a duplicate of the local repo in case it screws things up. My memory of the code suggests this will work.
I'd try using the transplant extension to fix this:
Re-clone the SVN repository to a new local repository.
Examine the history of the original repository and note which changes need moving
Transplant the changes from the old repository to the new repository
For example - fixing an hgsubversion repo called project:
> hg clone svn+http://svnrepo/project project-tmp
Then examine the log of your original project folder and do the following from the project-tmp folder:
> hg transplant -s ../project 1234
Where 1234 is the revision that you want to move over. Repeat this until all your revisions are copied.
When you're done you should be able to start using the new folder in place of the old folder by re-pulling from SVN, rebasing your changes and push them back (don't forget --svn)
I want to completely delete a Mercurial commit as if it was never entered in the repository and move back to my prior commit.
Is this possible?
If it was your last commit and you haven't pushed it anywhere, you can do that with rollback. Otherwise, no. Not really. Time to change your passwords.
Edit: It has been pointed out that you can clone from an older revision and merge in the changes you want to keep. That's also true, unless you have pushed it to a repo you don't control. Once you push, your data is very likely to be very hard to get back.
You can try to remove mq info about your commit.
For this you need to go File->Settings->Extensions.
There check mq and restart gui.
After that just right click on unneeded commit and
ModifyHistory->Strip
To edit the history I would use the Histedit Extension extension.
hg histedit 45:c3a3a271d11c
However keep in mind this only makes sense in a situation where you have not yet pushed the commits to the public repository, you own the public repository and/or you can account for all the clones out there. If you receive the following error:
abort: can't rebase immutable changeset 43ab8134e7af
It means that Mecurial thinks this is a public changeset (see phases) that has already been pushed - you can force it to be a draft again doing:
hg phase -f -d 45:c3a3a271d11c
I encounter this fairly often. I make a commit and then pull to push. But then there is something incoming that makes my newly made commit unnecessary. A plain hg rollback isn't enough because it only undoes the pull...
This is the thing to do:
hg strip <rev>
Things are painless when you don't push your changesets anywhere.
If it's more than one commit and/or you already pushed it somewhere else, you can clone your repository and specify the last changeset that should be cloned.
See my answer here how to do this:
Mercurial: Fix a borked history
If you only committed locally and didn't push, you can just create a clone locally (as described in my link) and you're done.
If you already pushed to some remote repository, you would have to replace that with your clone.
Of course it depends if you are able (or allowed) to do this.
You can use "hg backout" to do a reverse merge basically. All options are discussed in the freely available book "Mercurial: The Definitive Guide":
http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html
If using tortoise you can use modify history > strip...
Yes. Unless I am mistaken, as of v2.3 (rel. 2012/08/01) you can use the HisteditExtension with a drop command to drop a commit, along with strip or backout to remove changes.
A simple Google search on the feature: https://www.google.com/webhp#q=histedit+drop
In 2022 I do use evolve extension. It is one of the best extensions for this purpose.
To prune unwanted changeset, if you for example did a quick hack to get the code working:
$ echo 'debug hack' >> file1.c
$ hg commit -m 'debug hack'
Now you have a proper patch you can do hg prune .:
$ hg prune .
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
working directory is now at 2a39221aaebb
1 changesets pruned
If you push the change to the remote repository you will find only obsolescence markers:
$ hg push
searching for changes
no changes found
remote: 1 new obsolescence markers
To check the changes to your local repo you can pull from the remote one:
$ hg pull
pulling from ssh://userid#server/repo
searching for changes
no changes found
What is the best/easiest way (or is it even possible) to add an existing repository to another existing repository as a subrepo?
Situation is I have an existing (main) project where I want to include a library project so that i can edit the library project from the main project, and commit the changes to the library project when comitting the main project.
Also: Do I need to clone/push/pull to the original library project, or is this done automatically when committing in the main project?
Regards
Jesper Hauge
The subrepo documentation confused me so much so I wrote a shell script to abstract that part of it away.
addsubrepo.sh
Call it like
$ cd $TOP_OF_HG_PROJECT
$ addsubrepo.sh $URL_TO_HG_PROJECT relative_path/you/want_to/put_the_subrepo
Reading the docs, the subrepo plugin supports this functionality.
I haven't used it yet, but will likely start using it in the near future.
It is improved every release of Mercurial, and I believe people are successfully using it. It seems to get a reasonable amount of attention, and was on the agenda for the last coding blitz.
According to the help, pull, push, commit etc should act on the subrepo as well. It sounds like a commit will check if there are any changes in the subrepo. If there are, they will be committed, and the new changeset in the subrepo will be recorded in the .hgsubstate file. This file, as well as the changes in the main repo will then be committed.
When you clone, Mercurial should see the .hgsubstate as well as the .hgsub file, and correctly pull the subrepo, and update to the correct revision.
You might want to use the deps extension.
Here's how I did it:
$ cd /projects/main_project
$ hg clone /projects/plugins/awesome plugins/awesome_plugin
$ echo plugins/awesome_plugin = plugins/awesome_plugin > .hgsub
$ hg add .hgsub
$ hg commit -m "added awesome_plugin plugin as a subp-repo"