I am getting some .rej files while workin with mercurial. Can anyone tell me what are these and how to handle these?
When there are merge conflicts, or an applied patch fails to patch one or more chunks, the .rej files show the rejected chunks. They represent parts of the merge or patch that failed. If you've resolved the merge to your satisfaction, they can be deleted.
Related
In mercurial, the merge ignored some files (possibly a human mistake). How I can 're-include' the ignored files?
Scenario: the merge target(rev #47) has 5 files, but the merge(rev #50) has included just 1 file and others are ignored.
Apparently, when I check the resulting code, the code from Rev# 47 is missing.
You probably did the merge in a way you didn't intend, e.g. telling hg to only accept changes from one branch, discarding the changes from the merged rev47.
The easiest way is to start with a repo where the merge did not happen and re-do the merge. This is not possible, if it is a shared repo and that merge is already shared with others. If it everything local, but if that repo is your only copy, make a new clone without the merge: hg clone -r49 OLDREPO .
Thus if you cannot simply re-do the merge on a new repo without that merge, you'll have to go a longer way which is summarized in this answer. Note the screenshot in the accepted answer and DO NOT discard the changes from the merge target.
I use Tortoise Mercurial tool to manage my mercurial repository.
And I have a separate .diff file containin0g changes to a file in my repository.
Is there any way how to use that diff to update my file ?
thank you
Most Linux repositories comes with the patch program. You can then execute:
patch original.data difference.diff
Patch will modify the original.data file in such a way that if one would calculate the diff between the final and original state, one gets the same difference.diff again.
.diff files are in general not visible in a subversioning respository. They are stored internally to hide the several commits from the user. Diffs however can be usefull to analyze the difference between two commits. Say for instance somebody worked on your project and made a lot of commits, you might want to inspect what that person actually did without having to read the reports of all commits (since some changes can be undone in the next commit)
I've recently start using mq, which is a great way of working. One thing that annoys me slightly is that when I qpush back my patches after doing a pull and update, I end up with .rej files if there are conflicts.
It would be nice if Mercurial could just open TortoiseMerge so I can resolve the conflicts as quickly as possible, instead of having to open the .rej files one by one and do it in a more manual, slower way.
Even svn-style conflicts markers inside the files would be easier to work with than the .rej files.
Is there a way around those .rej files?
hg pull --rebase works, as long as you want to rebase your patches onto a newer base. You need have the patches you want to rebase qpushed. If the revision you want to rebase on is already in your repo, strip it and pull from the strip-backup bundle.
I have quite a few objects (.o) files in my (future) Mercurial repository. I have the source for most of them, but some were downloaded / provided by collaborators and I don't have the sources. Of course, versioning binary files is bad, but I'd like to do that for the few files for which I don't have the sources (given that they will rarely, if ever, be modified, and that on the other hand I cannot regenerate them myself).
Assuming that I have a simple way of determining where .c corresponding to a .o is if it exists (e.g. always in the same folder), is there an easy way to achieve this?
Thanks.
You can safely add *.o files to your .hgignore, and then manually hg add specific *.o files to the repository for tracking. Any automatic adding (such as hg addremove, or hg add without an argument) will still ignore *.o files, but you can manually add anything ignored and it will be tracked.
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.