I am trying to learn the merging and conflict-resolution workflow in mercurial. Am I supposed to commit any uncomitted changes in my working directory before I merge with another changeset?
What would happen if I merge before committing changes in my working directory?
Merging with uncommitted changes is a fundamentally unsound action. A merge can go wrong and when it does you want to be able to revert to your previous state, which is only possible if those changes are committed. If you can't bear to create a new changeset at that time commit them into a Mercurial Queue.
Related
Commits used to be rather fast, but now they take maybe 10 seconds. Other TortoiseHG operations such as update and push are reasonably fast, but commits have been slow lately. My repo has about 2600 commits; could it need some sort of reindexing to make it faster again? Or is committing always slow on such old repositories?
2600 changesets isn't "big repo" in common. Except ordinary OS-level management tasks, try to check state of repo with hg verify and consult Repository Corruption wiki for possible ways of eliminating of problems
Recently I have rewrote a lot of history (Forgive me Father, for I have sinned). Our old repository had a lot of sensitive information as well as unnecessary merges (up to 20 anonymous branches running simultaneously and being merged back indiscriminately), so I have striped several commits, pruned dead branches, rebased / squashed commits, rolled back unnecessary merges, created bookmarks, etc.
We now have a clean repo. I have also run unitary tests along several revisions to make sure that I haven't broke anything import. Yesterday I've forked the old repo (for backup purposes) and pushed the clean repository upstream. We are a small team and synchronizing changes was not a problem, every developer in my team is already working with the new repo.
Anyway, my local repository now have a .hg/strip-backup folder of around 2 Gigabytes.
From what I was able to understand, this folder contains backup bundles for every one of the destructive commands that I have run. I no longer need those.
My question is: Is it safe to remove the bundles inside .hg/strip-backup? Or will I corrupt my local repository if I delete those files?
Bonus question: Is there a built-in mercurial command to remove backups or should I just use rm .hg/strip-backup/*?
Yes, it is safe to remove the whole folder. The information contained in the folder is not relevant to the repo.
As a bonus answer, your best option to clean-up the cache folders is to simply re-clone the repo. Doing so allows you to start fresh and all the temporary files will be left on the base repo. Replace the original repo with a cloned repo and you won't have to bother with this history of temporary files for a while.
I have a gigantic repo and it takes a while to clone. Every time I make a few commits and realize I have goofed up, I end up deleting the current clone and re-cloning the repo. While this works, it is very very time consuming. Is there any command that I can use to just discard all my local changes and make my working folder look like my last pull?
You have a few options and both below assume that the changes only exist locally in your repo:
Have an additional local reference clone that only ever represents what the remote repo looks like. Then you can delete your current throwaway repo and reclone locally from your reference copy, which is much, much faster.
Utilize the strip function which will let you trim off branches of history. Please be very careful deleting history since it really is a double edged sword.
Is there a command to list all files that changed during the last update?
hg status --change tip
gives me just the files of the last changeset.
I could use
hg status --rev FROM --rev TO
but then I'd have to store the rev from before the update.
You could work out what will change prior to performing an hg update by doing a status and passing in the current and tip revisions: hg status --rev . --rev tip.
This will show you what files will change when you perform an update, but won't have any effect after the update, as mentioned by Tim Delaney. I am assuming that you want to know what has changed as you are doing an update after a pull? In which case it may be better to know what will change before you do the update anyway.
No. Mercurial does not store any information about the previous state of the working directory once an update has been performed. During an update it may store some state to help with recovering after an interrupted update, but nothing that would be useful for your use case.
Mercurial doesn't keep track of how often you run hg update, so it can't tell you which files were touched by the last update. However, it also doesn't mess with the modtimes of the affected files, so you can look at their timestamps to see what changed. To figure out which files were modified in the last five minutes, use
find . -mmin -5 -print
The alternative would be to record what mercurial will update, as #icabod suggested.
If after you do "hg update" you want to find out what changed during the update, you might try this:
First, use "hg log -l nn" to get a list of the revisions that are part of the most recent update.
Next, use "hg diff -r nn" to show all the differences since the revision before the update.
And, if you just want a summary of the files that changed, then use "hg diff --stat -r nn".
Is there a way I can modify the history in mercurial in order to split one commit into two separate commits?
The first of these should contain just renames/moves and the second should contain the edits. This would help with interoperability with other version control systems (e.g. perforce).
I'm hoping it's possible to automate this process with a script.
It's possible
With manual work
Using MQ extension
Fist we convert commit to MQ-patch, second - split into 2 pathes, last - qfinish patches into permanent changesets