I would like to abandon all changes in my bookmark and delete the bookmark itself.
I tried the instructions under: Mercurial - How to discard all local changes including to unversioned files?
i.e hg --revert .
In addition, I looked at Bookmarks where it says that the delete feature still leaves changed files. How do I go to a state where I can start afresh from the contents of the remote repository?
A bookmark is separate from the changes in the changeset. You can modify or delete the bookmark, and it keeps the changeset untouched. A physical bookmark is a good analogy: you can move it from page to page or remove it completely without altering the book contents - it's just a pointer to a page.
If you have committed the changes already into a changeset, you want to either back them out or strip them.
If you just want to start from the remote, delete your repository and re-clone it.
Related
I committed a changeset which is now in the "draft" Phase. It is the latest (local) revision. I want to remove that changeset and move all the changes back to the working directory. That means I want the opposite of committing it (which is working directory -> revision).
I tried the strip command with both keep and without. In both cases my changeset is removed but the changes are gone and the working directory is still empty. Then I need to unbundle the backup and pull it, at which point I'm exactly where I started with the local changeset in the history.
How do I move the changes from the committed changeset to the working directory? Maybe backout?
I'm using TortoiseHg but can also use the console there.
This doesn't directly answer the issue about the behavior of strip, but another way to do this in THG would be:
Shelve anything of value in your working folder
Update to the last-desired revision (the one before the revision you mean to undo)
Select the revision you want to undo and click "Revert All Files..."
Let it revert. The working folder will now match the revision you want to undo.
Strip (without "keep") the unwanted revision. Or even just leave it there and ignore it.
Looks like I managed to solve it, though I don't really understand how it works.
Following this answer I updated to my revision, switch to Ammend which showed the patch changes in the working directory as well as the revision, then strip with keep removed the revision, only the working directory now contains the files because of Ammend.
I have seen Remove file from a commit in Mercurial - but I have very little experience with Mercurial, so I'd like to ask and make sure if this is doable, and how.
There is a software that is developed in Mercurial, and I wanted to try and add a feature. So when I cloned the repo, first I did was added my own branch, and started hacking there. Already in first or second commit of this branch, I added multiple files hg add test1.bmp, hg add test2.bmp and so on, and committed.
Then I kept on hacking other files (haven't touched these test1.bmp, test2.bmp etc since), and made about 3 or 4 commits after the commit where the bmps are added. Nothing has been pushed anywhere - my local copy of the Mercurial repo and my branch in it is the only place where these files are referenced. And just now I realize I shouldn't have added those files at all.
Is it possible to remove these files from all of the commits where they feature, since the first commit where they were added?
Or maybe I should formulate the question in singular - is it possible to remove a file from all of the commits where it features, since the first commit where it was added? (if it is possible for one file, then I can just repeat the process for any additional file I'd like to remove)
Yes this is possible.
However, this is a more advanced use of mercurial and will require you enabling at lease one extension.
As a new user, my recommendations would be to simply use mercurial basic management and remove the file(s) of concern:
hg remove <file>
You can then commit the change.
While this will not remove the file(s) from all changesets, it will remove it
going forward. This honestly is the recommended way of managing working content.
It should be noted that this is likely your only option if you have pushed changes to the parent repository. If you have pushed your changes to the parent repository, you will also have to edit it which makes things much more complicated and the potential for a serious mistake more likely.
If you truly want to remove it from previous changesets, you will need enable the histedit extension (included with mercurial).
[extensions]
histedit =
Since you are a relatively new user to mercurial, I strongly recommend that you backup your repository and experiment there before attempting this on you working copy.
The process I recommend for this is as follows:
Note: this only works as described for changesets that have not been pushed and have phase = draft (or secret)
1) Identify all changes where file(s) are added or modified
You will need to know each changeset where the file(s) where modified or added. You will need to modify each of these changesets in the reverse order that they where added.
You can use:
hg log file
to list changesets where the file was modified or added.
2) Slowly edit each affected changeset (working your way backwards)
Use the histedit to display all show all changesets that can be modified/edited in your default editor.
hg histedit
Find the first changeset you identified and change it from pick to edit and save the change.
This will drop you into histedit edit mode. This is the state just before the changeset was committed. This means you can make changes such as modifying, unedifying. Adding or removing content. In this case we want to undo any changes to the file(s) in question.
hg revert file
or
hg remove file (if this is the changeset where the file as added)
3) recommit changeset
Once you have reversed the file changes/additions, you need to inform histedit
that you are done.
hg histedit --continue
This will cause the changeset to be recommitted with the modifications you made including editing the commit message.
Repeat this for each changeset until completed.
Note: While you can select multiple changes to edit in histedit, I recommend doing one at a time to help reduce complexity. Remember to do the in the reverse order that they where committed to help reduce / eliminate any merge conflicts.
Again a recommend practicing on a repository copy until you have the process firmly understood. Since you are modifying repository history, this can have potential negative effects of a mistake is made.
I highly recommend reading this: https://book.mercurial-scm.org/read/changing-history.html.
I just found out that we're not supposed to create named branches in our local Mercurial repos, because they get carried along and pushed to the upstream repo, where they live forever.
Unfortunately, I already have multiple feature branches in my local repo, which I was all set to merge to default and push up to the main repo. So, what I need to do is keep the work in these branches (somehow) but remove the named branches.
Is there a way to do this, short of a lot of horrible manual revert/cut/paste?
Using TortoiseHg:
(Ensure rebase extension is enabled in File -> Settings -> Extensions)
Update to parent of the first change set of the named branch.
Right click on the first change set of the nambed branch and click rebase.
Ensure "Keep orignal branch names (--keepbranches)" is NOT checked.
Ensure "Rebase entire source branch (-b/--base)" is checked.
Click rebase.
Another approach would be to use the hg convert command (a standard extension) and the branchmap option.
For a private repository or at least one with changesets which have not been published this would work fine, even though like a rebase it would modify history.
An advantage as opposed to using rebase is that it could be used to deal with multiple branches (named or unnamed) all at once. That might be quicker / easier if there was a lot of things to move around.
A secondary plus is that since convert will create a NEW repository there is no risk to the original if something doesn't work as expected. (Of course when using rebase you could make a backup first which I think is a reasonable precaution.)
I am a little confused about how to rollback to a tag in Mercurial. (which I am very new to)
Say I have a tag called "Version-1.0" which was several revisions ago. lets say we are at r400 now
Now if my managers were to tell me they don't like the direction things have been going and basically want to ditch everything since that tag and go back to Version-1.0.
Well I can checkout that tag with:
hg update -r Version-1.0
Ok so now I am back to the version 1.0 tag, and if I were to never need to make a change this would be fine. However, as soon as I make a change and commit, I now have 2 heads (my new changes to Version-1.0 and r400 the stuff the managers want to ditch).
So now I need to merge with r400. I don't want to. (I don't really want to wipe all those changes off the earth, I would like them to remain in my history so I can go back to them later if management changes their mind again) but I currently don't want any of them.
What do I do?
update
An answer stated:
You could clone the entire repository up until the tag, then use that clone as your "new" central repository.
If my central repository is hosted by bitbucket, I am not sure how to do this. If the current one is at URL https://jisaacks#bitbucket.org/jisaacks/hgml and I want to clone it up to the tag to a new repo named hgml2 (that doesn't exist yet) I tried this command locally on my machine:
hg clone -r Version-1.0 https://jisaacks#bitbucket.org/jisaacks/hgml https://jisaacks#bitbucket.org/jisaacks/hgml2
I get this error:
abort: cannot create a new http repository
Log on onto bitbucket and click the "Fork" arrow icon in the upper right corner. Now you can open the "advanced settings" to fork from a tag.
You could then rename the first repository to something like "myproject-abandoned-foo-changes" and reuse the original name for the forked repository, where you will continue development.
edit: you could also do a no-op merge. The linked wiki page explains that this might be bad because your history will be contaminated with the unwanted changes, but I think in your case this might be exactly what you want as it would preserve your changes while avoiding the "switching everything to a new repo" issue you complain about.
You can use hg revert. The following command restores your repository to a certain tag and discards all local changes.
hg revert -r tagname --all
The "correct" way to do this in modern Mercurial is to close the branch:
hg up head-i-dont-like
hg commit --close-branch
While this was originally added to close named branches, it works equally well with anonymous branches (what the OP has). In particular, it will only affect the head it is committed on, and not any other heads on the same named branch.
In our Mercurial repo we added a really big file (and did an hg push), then deleted the big file (and did another push).
Now if someone does an hg clone will they still pull down that big file? I know it won't appear in their working directory as it was deleted, but will the file still be pulled down and stored in Mercurial internal storage?
I'd like to ensure people don't have to pull down the file. I've learned that really big files should be stored outside of Mercurial, so I deleted the file. But I was wondering if people will still be pulling down the big file - in which case I guess I will recreate the repository from scratch.
Of course it will still be in the repository.
You can always update back to older revisions, and if you update back to the revision you got when you committed the file, it'll be there in all its glory.
There are two ways to mitigate this (when you're committing, not now):
One of the big-files extensions, these essentially add big files to a secondary repository and link the two, so that if you update to a revision where the file doesn't exist, and you don't already have it, it will not get updated. ie. it's more a "on-demand" style of pulling
If the file never changes, keep it available on the network and just create some kind of link to it instead of a full copy
Right now, you got four options:
Strip away the changeset that added the file, and all the changesets that came after it. You can do that using the Mercurial Queues extension. Note that you need to do this stripping in all clones. If just one of your users push back the repository that has that file in its history to the central clone, you have the changesets back.
Rebuild the repository from scratch manually
Using the hg convert command and some filtering, the --filemap option can be used for this
Leave it as is. How big is it, will be much of a problem?
Note that rebuilding the repository, either manually or through hg convert will invalidate all clones. Anyone trying to push to your new central clone from an old clone will get a message about unrelated repositories. If any of your users are stupi^H^H^H^H^Hnot smart enough to realize that forcing the push is a bad idea, then you will have problems with this approach.
Yes, the file is still in the history. If you want to delete it completely, you need to use Mercurial Queues — see Editing History on Mercurial wiki.
Just keep in mind this breaks clones as revision IDs change.