I have a file that should be added as binary but currently is not.
Is there a way I can force hg add the file as binary?
The file is an image that is corrupted (on purpose) for a test case.
Update: The problem in particular is that I have a patch file, so when I apply the patch it does not apply the same.
As per its documentation, Mercurial does nothing special for binary vs. text files. So you don't need to do anything special either, other than refraining from running diffs on them.
As John says Mercurial doesn't differentiate between binary and text files internally. It does display them differently in diff/patch output, and it provides binary-usable diffs for files the output filter thinks might be binary if you use the --git option (for git-style diffs). When decided whether or not to show a file as binary (show, not store) it bases the decision on whether or not there's a NUL (0x00) byte in the file. Try to get one in there if it really matters. Alternately consider sending a bundle (hg bundle) rather than a diff.
Related
I'm trying to compare and merge MySQL WorkBench files in SourceTree, and in order to do so I created a small shell script that extracts the content of the .mwb file and strips some useless counters from the XML file inside it.
Then I added this line to .gitconfig in the project's root:
[diff "mwbdiff"]
textconv = mwb-diff
and this in the .gitattributes:
*.mwb diff=mwbdiff
Now, if I change something on a .mwb, then "git diff" on console shows the correct differences, and SourceTree does it, too:
The problem is that if I try to do the same on already committed versions, I get nothing:
Same result if I try to merge. I still get the right output if I try to run GIT from the console like this:
git diff develop feature/four -- test.mwb
but if I try to merge, then I get unsolved conflicts and I don't know how to proceed.
I also tried to move the .gitattributes and .gitconfig changes into the global variables, and it actually works in the console, but it didn't help SourceTree.
I suspect it has something to do with the binary preview in SourceTree (Mac version), if I could disable it...
What am I missing? How can I solve this problem?
I think that this is not supported.
So to avoid calling git diff when it will ultimately just produce no output, SourceTree pre-detects whether files are binary or text on the disk, identified by whether in a quick sample of the initial chunk of the file contains a couple of binary zero's in succession. I can only assume that the odt formats include this sequence, so SourceTree treats them as binary. On Mac we have a binary preview pane which displays before/after of supported binary files but we haven't ported that to Windows yet.
At the moment we don't support your case and may not add it in the near future, because it's a pretty rare thing to do and most people would just see a performance penalty when git diff fails and we then fall back on other techniques. We'll keep this logged for possible future support.
Source: JIRA - textconv diff not generated
So in other words, SourceTree specifically avoids calling git diff for files that SourceTree considers to be binary. That means that any textconvs don't get called at all.
The only way to work around this would be to trick SourceTree into thinking that your file isn't binary. Which is probably not feasible.
Is there a way to tell Mercurial that a specified ascii file should be completely overwritten rather than merged during future updates, similar to the treatment of a binary file?
Git handles this using .gitattribues, as described here: Git mark file as binary to avoid line separator conversion. Is there a Mercurial equivalent?
Have a look at merge-patterns (in the hgrc). This allows you to specify internal:other as the merge action.
I recently converted a CVS repository to Mercurial. From the looks of it, everything went perfect. Except that every end-of-line character is in Unix style and I want them in Windows style.
I know the hg convert command can be used to "convert" a Mercurial repository to a Mercurial repository. Can I use it to do nothing on the repos but fix the line endings?
How they're stored in the repo isn't terribly important since you do your actual work with the checked out working directory, whose line endings you can control at update time using either of these extensions:
Win32TextExtension
hg-eol extension
more detail is available here: https://www.mercurial-scm.org/wiki/EOLTranslationPlan
I don't think there's an easy way to get hg convert to do what you want (short of writing code that plugs into convert's code. Unfortunately, convert's hg-to-hg conversions are also not entirely clean, due to the generalized model convert has. This may not be a problem if you're coming from CVS, though.
One way is to use whatever tool that normalizes line endings and run it on every file in a checked out copy then commit every file. But that should be considered a last resort solution since it will make the history "dirty" (files will appear to have been changed when they practically have not been).
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why does Mercurial think my SQL files are binary?
I've recently started using Mercurial and when I reverted one of my .SQL files, Mercurial performed a binary comparison. This obviously limits the visibility of the changes that were made, as there is no diff.
Is there an option to set file types to do a string compare?
I'm using Tortioise Hg 0.8.1 with Mercurial 1.3.1.
Mercurial doesn't actually handle text and binaries at all differently with respect to actual storage. It does however try to guess "would visually showing this diff be meaningful" when asked to show a diff to a user with hg diff, hg log -p, or when viewing a changeset in the web interface. When it's trying to make the "should I show this as if it's text" decision the test applied is "Is there a NUL byte (0x00) within the first 1000 bytes of a file.
So your file isn't being treated any differently except in how it's displayed to user output, but if you can find a NUL byte in there you can probably get that to stop too.
Alternately, the extdiff extension can be used to take total control of how diffs are displayed.
I don't know about the graphical part of TortoiseHg, but if you use the command line, then the --text flag to hg diff should do the trick: it makes Mercurial treat all files as text.
You should try adding these lines to ~/.hgrc:
[diff]
git=1
The git diff format works for binary files.
I converted my CVS repository into SVN repository.
It worked great, but one problem had occured....
I converted using a dumpfile, and the command was:
cvs2svn –encoding=( ) –sort=(PATH TO sort.exe) --default-eol=native –dumpfile=PATH\name.svn_dump –svnadmin=(PATH TO SVN ADMIN) (PATH TO REP)
loading the dump file:
svnadmin load PATH (to repository location) < PATH\name.svn_dump
Now some binary files, which in CVS are marked with -kb, have been corrupted. If I open both versions of a file in WinMerge, there look the same when the "Ignore Carriage Return Differences" is checked.
What seems to be the problem?
Did I miss something during the conversion?
thanks,
Oded.
Since you used the --default-eol=native option, any binary files that were not marked as binary in CVS will be stored to Subversion in "native" EOL encoding and will typically have problems like you described when checked out of Subversion. So, are you really sure that the files in question were marked as binary in CVS?
Please also note that there is a more proprietary CVS-like program called CVSNT whose repository format is different in several details to that of CVS. For example, it stores file modes in a way that is incompatible with CVS. cvs2svn does not support converting CVSNT repositories. If your repository was ever touched by a CVSNT client, you might have difficulties with your conversion. In that case, follow the tips in the above link and also consider setting the files in question to binary explicitly, for example using cvs2svn's --auto-props option.