I use vimdiff as my merge tool in mercurial. Sometimes I'll start a rebase that ends up being pretty messy and I just want to try and get out of the process and do something different. The way I end up doing this is usually just spamming :qa until I've made my way through all the conflicting files, but for larger sets of conflicts this can mean I'm doing that for quite a while. Sometimes, if I'm lucky, I can sneak in Ctrl+C in the time before the next conflict loads up in vim, but often I just end up messing something even bigger up and my whole terminal session is hosed.
Is there a more graceful way of quitting out of a messy rebase when using vimdiff?
From vimdiff, you can use the :cq command to quit Vim with an error code.
Mercurial should be able to tell that this happened and interpret as you telling it to stop the operation, giving you the opportunity to break the merge operation.
You can use Ctrl+Z to suspend the foreground process (which is vimdiff, but also the hg that spawned it), dropping you back to the shell.
At this point, you can kill the foreground job with kill %%, or perhaps kill -INT %% (SIGINT is equivalent to pressing Ctrl+C), which should kill the hg process and terminate vimdiff with a SIGHUP (Hang-Up).
By suspending vimdiff, you manage to find the time to send hg the equivalent of a Ctrl+C.
Related
I have a utility script that will configure the local developer instance to mimic a specific production one - copy over the correct connection strings, client files, etc - thereby making it easy to investigate certain issues.
Because this is all done locally this changes files in the working directory. The first thing the script does therefore is print out a big fat warning to caution developers not to commit and revert changes when they are done. However it is possible to forget or miss this warning as cruft from my build system scrolls by and I wonder if its possible to go further.
Is it possible to do something to the hg repo so that a commit will be rejected and the developer would have to revert first?
I realize there are some variables to the question as far as revert what and commit what but given that I'm not even sure that this is possible, I am willing to take close-with-caveats for an answer.
This is exactly what hooks are for. You would need a precommit hook on every repo or possibly the pretxnchangegroup.
By creating a precommit hook (script) that checks for a specific file or a specific change, you can fail the commit and print out whatever warning you need. The return value of the script indicates to mercurial if the transaction is valid or not.
Use the following generic sample to check for the presence of certain files that would be committed, before accepting or rejecting the changesets.
I use the hunk-by-hunk or hunk selection approach to committing: instead of commuting all changes I made to a file, I commit related parts. E.g. I wrote a function and a test, compiled to ensure it works and then commit the function and the test separately. For this I use built-in functionality in tortoiseHg and RecordExtention when in the console.
Now I have two edits separated by only one unchanged line, thus falling in hg's tolerance of one hunk. I want to commit only the former for now. How?
The record extension doesn't let you split hunks further, but the less-standard CRecord extension does.
Just to put it out there, but what you're doing is usually considered bad practice because it guarantees that you haven't run the unit tests on the files as they're being committed. That, of course, doesn't apply in all environments.
If the reason you're leaving some parts uncommitted is because they're local-only changes you always in in place (passwords, paths, etc.) they're a good candidate for a Mercurial Queues "patch". Then you'd be able to 'pop' them off, commit the whole file, and then 'push' them back on.
The Problem
Pulling changes from our Sourcerepo mercurial repository used to take very little time, e.g. a couple of seconds. Now it takes enough time for me to go get a drink and have a wee (a few minutes). It is getting incrementally slower as, I presume, a function of the size of the history on the repository. This is really annoying, there's only so much drinking and weeing I need to do, it's starting to hit my productivity.
Context
The repo is on Sourcerepo.
I'm connecting to the repo over ssh SSH with key based authentication.
I'm using TortoiseHG as my tool of choice, though the issue is equally seen via the command line.
It takes a long time to check for incoming changesets, it's the pull not the
update that's taking the time.
If there are no changes it only takes a few seconds to tell me that.
We use a lot of named branches, we do close them after ourselves so there's 5-20 open at a time but hundreds in the history.
We've got a little under 3k revisions in the repo.
Pushing is still really fast.
I thought Hg used some sort of delta encoding to only get the changes, it shouldn't be taking this long. I wondered if there was an option I was missing in Hg or if anyone else has experienced this behaviour?
Thanks in advance :)
You can try
hg incoming -v --time --profile --debug REPO-URL and read output - it can shed some light on most slow parts in process
Clone Sourcerepo to local repository and test incoming against this repo (eliminate network-related latency)
If nothing help
clone smaller parts of repo (from 1 to tip) and test incoming for these truncated clones in order to identify changeset (I hope), which brings this headache: I can't see how to use bisect on single big repo for test incoming operational time
I'm working on a project which is using mercurial and it's gotten into a bit of a mess with a number of heads which for all intensive purposes are dead.
I want to kill off these heads and bring the commit graph back to a single line.
I've been told there's a way to merge branches but at the same time ignore any file changes, so essentially just merging the tree, but I can't seem to work out the command set.
Is there a way to do this, kill off branches by doing merges and ignoring the file changes? Or alternatively is there a way to bring in the graph again without the changes (which are not massively irrelevant in the project)?
If you are using TortoiseHg and named branches, you can select the branch option in the commit dialog to close a branch and it will allow you to commit without having an actual file change.
It will still leave you with a head, but it will be marked inactive.
I think this is just what you're looking for:
Keep My or Their files when doing a merge
It'll create new merge changesets that close down the "other" head w/o taking in any of its changes. You won't end up with a linear history but you'll end up with a single head.
Other inferior answers include using hg strip or hg clone -r to eliminate the heads/anonymous-branches you don't want. They're inferior because (a) if other clones exist you can't strip it doesn't work at all and (b) they throw away history which is the opposite of good version control practice -- even work you don't think you want now may be valuable someday.
We are just beginning to learn and evaluate Mercurial, due to an increasing number of nightmare merges, and various other problems we've had with SVN lately.
A client wants us to pull down a live copy of their site, do some SEO work on it, and push it back to them. They have no source control at all. I figure this is a great project to work on with Mercurial. Instead of putting it into our SVN and exporting when we are done, we'll use Mercurial... But right away it seems I have some problem :)
They have a file called ---.config which seems to cause our Mercurial to barf. It just can't commit that file. I've created the repo and committed everything else, but I just can't get this one file committed.
We are running on Windows 2008 x64 with TortoiseHG 1.0.
I suppose I could ignore the file since it is unlikely we'll need to work with it, but still - I'd like to learn how to use Mercurial a bit better. Is there a way around this?
EDIT: here is the error message:
('commit', GetoptError('option ---.config not recognized', '-.config'))
This happens when I hit the "commit" button in TortoiseHG with that file selected.
Not sure about hg, but most command line tools treat anything after a -- as a non-option. This is helpful if you have a filename that starts with -- or a wildcard that picks up such a file; try prefixing your filename or wildcard with --, e.g., hg command -- *.config.
The problem is that TortoiseHg did not escape filenames correctly when calling hg. When a filename starts with --, one must take extra care when using it on command lines.
I have just sent a patch which will hopefully make it into TortoiseHg 1.0.1, which is scheduled to be released later today.