I pulled my project from bitbucket. Then at merging it mercurial says: abort: filename contains ':', which is reserved on Windows: 'uploads/images/ \xd1\x8d\xd0\xba\xd1\x80\xd0\xb0\xd0\xbd\xd0\xb0 - 29.03.2012 - 19:41:35.png'
How I can remove this file from repo? I don't need it, but it aborts merging. I don't see this file in folder in Windows.
On a windows system you could do something like this:
hg clone --noupdate PATH_TO_YOUR_REPO
hg debugsetparent tip
hg remove --after "uploads/images/\xd1\x8d\xd0\xba\xd1\x80\xd0\xb0\xd0\xbd\xd0\xb0 - 29.03.2012 - 19:41:35.png"
hg commit "uploads/images/\xd1\x8d\xd0\xba\xd1\x80\xd0\xb0\xd0\xbd\xd0\xb0 - 29.03.2012 - 19:41:35.png"
After that you could update and then merge. Probably easier just to do it on an OS with a more forgiving file system though.
Related
It seems like ShelveExtension only shelves your modified files leaving untracked or deleted.
I am new to Mercurial and coming from git so for me this is not expected.
Even bigger problem I am not able to hg unshelve with what I assume is an error message.
See below:
unshelving change 'main'
temporarily committing pending changes (restore with 'hg unshelve --abort')
rebasing shelved changes
abort: uncommitted changes
Is that an expected behavior and I am just missing something?
How could I unshelve my modified files without restoring/committing/etc.?
Is there an extension which behaves exactly like git stash?
Steps to reproduce:
Environment:
OS: Windows 8
Mercurial: Mercurial Distributed SCM (version 3.0.1).
Installed as cygwin /usr/bin/hg (Tortoisehg is not installed, Windows hg is installed but not used)
Extension: ShelveExtension.
Is that an expected behavior and I am just missing something?
Yes, this is normal behavior. You need to do hg addremove (or manually hg add and hg rm the individual files) if you want Mercurial to track file creation and deletion. Renaming should be done with hg mv. This is vaguely similar to git add, except that you do not need to do it for modified files.
When you unshelve, your working directory should be clean. At the very least, it should not have any missing files (prefixed with ! in hg st) nor any modified files (prefixed with M). You can always make a temporary commit and hg strip it later.
How could I unshelve my modified files without restoring/committing/etc.?
There's no sane way to do this in the general case. What if the shelf contains changes to a file which no longer exists? If the file deletion had been committed, you could generate a patch conflict, and that's what Mercurial does. But without a commit to conflict with, there's no obvious response to this situation.
Is there an extension which behaves exactly like git stash?
Not to my knowledge, but this is beyond the scope of StackOverflow.
There are two heads on my repository. I have five files that I've edited locally. The Bitbucket repo has 15 changed files that I haven't edited, but it also contains changed versions of the same 5 files.
I'd like to do the following:
1) If I've edited a file and the Bitbucket repo contains the same edited file, I'd like my changes to take preference.
2) If I haven't edited a file, I'd like to update to the latest version.
What sequence of commands in Mercurial will let me do this? Do I have to use an external program?
WITH LOCAL COMMITS
hg pull
hg update --rev ${my version}
hg merge --rev ${their version} --tool internal:local
See also hg help merge-tools
WITHOUT LOCAL COMMITS
hg status -qn gives you a list of files you have changed. Since it's only five files, I'd copy them away manually, then revert, pull, update and copy them back into place. On unix you could write a throw-away shell script, something that goes kinda' like this:
ls -l *.mine # check to see that there are none
for file in `hg status -qn`; do cp ${file} ${file}.mine; done
hg revert --all; hg pull; hg update
for file in *.mine; do cp ${file} ${file%.mine}; done
This is untested code. Run it at your own risk. Eat muffins and be happy.
just do
hg pull
hg merge
This will pull the latest changes from bitbucket and allow you to merge your local changes the way you want.
This is really a basic functionality, you should read some documentation about mercurial, for example HG Init like said in the comments.
I am familiar with TFS and Vault, but having just started using Mercurial I seem to be getting into a bit of a mess.
Heres what I (think) I've done:
-Created a central repository on bitbucket.org
-On my desktop PC, cloned repository from bitbucket, added files, commit them, push them to bitbucket
-On my laptop, cloned repository from bitbucket, pulled files, added more files, commit them, push them to bitbucket
I've continued to add, edit etc on the different computers.
Now I've noticed that some files from each computer are not in the bitbucket repository, and therefore only in the local repository. No amount of pulling and pushing seems to get it into the bitbucket repository.
What is the most likely thing I've done wrong?
Is there a way to 'force' by changes up to the bitbucket repository?
Did they get into your local repository? I suspect not, i.e. they were new files that were not added to the commit. Use hg add to add them to the changeset before committing or whatever the equivalent is for whatever mercurial interface you're using.
Edit:
Here's the help from Mercurial:
C:\Users\Bert>hg add --help
hg add [OPTION]... [FILE]...
add the specified files on the next commit
Schedule files to be version controlled and added to the repository.
The files will be added to the repository at the next commit. To undo an
add before that, see "hg forget".
If no names are given, add all files to the repository.
...
See Mercurial: The Definitive Guide (a.k.a. the hg "red book") for more info:
http://hgbook.red-bean.com/read/mercurial-in-daily-use.html
Telling Mercurial which files to track
Mercurial does not work with files in your repository unless you tell it to manage them. The hg status command will tell you which files Mercurial doesn't know about; it uses a “?” to display such files.
To tell Mercurial to track a file, use the hg add command. Once you have added a file, the entry in the output of hg status for that file changes from “?” to “A”.
$ hg init add-example
$ cd add-example
$ echo a > myfile.txt
$ hg status
? myfile.txt
$ hg add myfile.txt
$ hg status
A myfile.txt
$ hg commit -m 'Added one file'
$ hg status
use "hg -v help add" to show global options
I am looking for best practices to do the following:
When I need to implement a feature or fix a bug, I am creating new Mercurial repository from the main one (a trunk).
Then, within some days, or weeks, I am implementing the task in newly created repository, making commits and periodically merging with trunk. After the code in new repository will pass all code reviews, I should provide a repository with all changes collapsed into single revision.
My common way to do this (rdiff extension should be enabled):
hg clone ~/repos/trunk ~/repos/new-collapsed
cd ~/repos/new-collapsed
hg diff ~/repos/new > new.diff
patch -p1 < new.diff
hg commit
This works almost well except when there are binary files present in the changes from ~/repos/new. Another way could be:
hg clone ~/repos/trunk ~/repos/new-collapsed
cd ~/repos/new-collapsed
hg pull ~/repos/new
hg update
hg rollback
then resolve possible conflicts and manually commit the changes
Both ways look for me somewhat ugly and non-native, so I am looking how this operation could be simplified. I've played with rebase extension, but seems its hg rebase --collapse command does not work with workflow described above.
Any ideas are welcome.
Sounds like a good case for mercurial queues.
I do something similar with the histedit extension.
My workflow is something like:
clone a central repo
commit incremental changes to local repo
clone my local repo to make collapsed repo
hg histedit and select/discard/fold the revisions as needed
hg push the collapsed repo to central repo
pull central repo to local or refresh local from scratch
I ensure that my local repo never gets pushed to the central repo by adding an invalid default-push path to the .hg/hgrc file in the local repo root directory.
Solved: Just add
[diff]
git = True
to your hgrc file, and then use my first solution with rdiff extension, replacing patch with hg import:
hg clone ~/repos/trunk ~/repos/new-collapsed
cd ~/repos/new-collapsed
hg diff ~/repos/new > new.diff
hg import new.diff
hg commit
I have a merging conflict, using Mercurial 1.0.2:
merging test.h
warning: conflicts during merge.
merging test.h failed!
6 files updated, 0 files merged, 0 files removed, 1 files unresolved
There are unresolved merges, you can redo the full merge using:
hg update -C 19
hg merge 18
I can't figure out how to resolve this. Google search results instruct to use:
hg resolve
but for some reason my Mercurial (v1.0.2) doesn't have a resolve command:
hg: unknown command 'resolve'
How can I resolve this conflict?
To highlight an answer in a comment for Hg 1.1+:
For Hg 1.1+ fix the file by hand and then do
hg resolve -m test.h
to mark the file as merged.
Valid for hg < v1.1 only
There is no need to call any hg commands. Unlike svn, Mercurial does not track conflicted files. If you call hg status, you'll see that the file is simply marked as modified.
Just fix the file by hand and commit.
Tracking conflicts was introduced in Mercurial 1.1, which is a newer version that you are using (you should really upgrade, Mercurial 1.1. was released in December 2008).
In that version you gained the resolve command which works similarly to svn resolve.
As I remember it, Mercurial would leave merge markers (the <<<< and >>>> lines) in your file when there is a conflict, unless you have configured a merge tool. This also applies to newer versions -- I have no merge tool configured and get the merge markers when conflicts occur. I can then manually fix the file and mark it resolved with hg resolve.