I am using kdiff3 with TortoiseHg.
When merging file in utf-8 encoding, kdiff3 show all non-latin text like
"склад".
How I can fix this?
In Kdiff3
Main menu: Settings - Configure Kdiff3 - Regional settings tab
Select "Unicode, 8 bit" in case of UTF8 without BOM or enable "Auto detect Unicode" in case of UTF8-BOM
Related
I'm using Hg mercurial 2.8.2.
My problem is about commit message when I commit using command line.
Like "hg ci -m 'my test 가나다'" , mercurial rejects commit (space tab and Korean).
How can I solve this problem? Do I have to re-install with another version?
If I have to revise specific config file, please let me know where it is.
(ps, My platform is 'Win7 - 64bit')
Thanks.
You need to set HGENCODING system environment variable to utf-8
To do that open Windows Control Panel -> System -> Advanced System Settings -> Environment Variables
Add New variable and enter following values:
Variable name HGENCODING
Variable value utf-8
Additional links about encoding issue:
Mercurial Encoding Strategy
Mercurial Character Encoding on Windows
I have TortoiseHg installed on Windows XP. Although I can use most hg commands normally from the command line, I cannot use hg commit (without the -m option) because it fails to launch my editor. This is what happens:
> hg commit
/c: /c: is a directory
abort: edit failed: notepad.exe exited with status 126
in mercurial.ini I have the editor set as:
[ui]
editor = notepad.exe
If I myself type notepad.exe or even just notepad from the command line then notepad works fine. Changing the editor variable to something else (like to foobar) confirms that Mercurial is reading the variable and trying to run foobar with the same result (foobar exited with status 126).
I also have a problem using parts of the TortoiseHg GUI. Context menu options like "View at revision" don't work when clicked. Presumably they are trying to launch the editor but are failing.
This problem has persisted for about 2 1/2 years of using Mercurial, and I've tried everything I can think of to set the editor variable in another way or set it to another program. Currently using TortoiseHg version 2.8 ("with Mercurial-2.6, Python-2.7.3, PyQt-4.9.6, Qt-4.8.4").
related questions:
Using other editor with TortoiseHg
How do I specify a different editor for Mercurial on Windows?
Mercurial Editor: "abort: The system cannot find the file specified"
Not long did I ask this question before finally realizing the problem. Mercurial and TortoiseHg are running the value of my Editor variable into a command interpreter, and this interpreter is whichever is specified by the COMSPEC enviroment variable.
Apparently once in my life I set this variable to the msys shell C:\msys\bin\sh.exe (probably in a vain attempt at trying to fix a problem not unlike the one I was asking here). The funny errors were caused because the msys shell being sent something like /c notepad.exe as an argument.
I have no idea why the extra /c switch is being passed (which is cmd.exe specific) if Mercurial is also deciding to also use COMSPEC. Also, when editing the settings from TortoiseHg, I am somewhat misleadingly told that if the Shell value in my mercurial config file is left unspecified, then it will default to cmd.exe on windows. This value of Shell is probably used for something else though, like the 'Open Terminal' context menu.
I have installed Mercurial from the Ubuntu package repository. However I don't know how to enable extensions (q* commands). How should I do that? The help shows that
enabled extensions:
style (no help text available)
I want to enable mq and hgk.
Enable extensions in hgrc.
extensions
Mercurial has an extension mechanism for adding new features. To
enable an extension, create an entry for it in this section.
If you know that the extension is already in Python's search path, you
can give the name of the module, followed by =, with nothing after the
=.
Otherwise, give a name that you choose, followed by =, followed by the
path to the .py file (including the file name extension) that
defines the extension.
...
Example for ~/.hgrc:
[extensions]
# (the mq extension will get loaded from Mercurial's path)
mq =
# (this extension will get loaded from the file specified)
myfeature = ~/.hgext/myfeature.py
http://www.selenic.com/mercurial/hgrc.5.html#extensions
You can also enable an extension without editing the hgrc, if you want to do it one off. [Source]
hg --config extensions.histedit= --help
The documentation of both extensions shows how to enable them : MQ, Hgk.
The usual way to enable an extension is to add a line to your .hgrc (or Mercurial.ini on some Windows system). It is explained in the hgrc documentation.
In your following case, add this to your configuration file :
[extensions]
mq =
hgk=
You can put it in your global configuration file or the repository one, depending if you want to have the extensions activated in every repository or just a specific one.
The output of hg help extensions starts with
Using additional features
Mercurial has the ability to add new features through the use of
extensions. Extensions may add new commands, add options to existing
commands, change the default behavior of commands, or implement hooks.
Extensions are not loaded by default for a variety of reasons: they can
increase startup overhead; they may be meant for advanced usage only; they
may provide potentially dangerous abilities (such as letting you destroy
or modify history); they might not be ready for prime time; or they may
alter some usual behaviors of stock Mercurial. It is thus up to the user
to activate extensions as needed.
To enable the "foo" extension, either shipped with Mercurial or in the
Python search path, create an entry for it in your configuration file,
like this:
[extensions]
foo =
You may also specify the full path to an extension:
[extensions]
myfeature = ~/.hgext/myfeature.py
So just add
[extensions]
mq =
to enable the MQ extension.
I recently acquired a MacBook. I compiled Mercurial 1.6.3, and set it all with NetBeans.
The thing is, whenever I try to commit, and since I'm writing the revision message and my name with accented characters (in Spanish), I'm getting an error like:
transaction abort!
rollback completed
abort: decoding near 'Naim? Batuta ': 'utf8' codec can't decode byte 0x8e in position 4: unexpected code byte!
I used locale on the console, and I got this:
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=
I tried setting LC_CTYPE="C.UTF-8", and now LC_CTYPE became ="C" as well, yet Mercurial keeps showing me the same message.
At first I thought it was NetBeans switching character encodings, but then I tried a simple hg commit, and it returned the same error.
I've read everywhere, and while such articles mention character encodings of Mercurial, Mac OS X, and Python, some patches to fix it (a while ago, so they should be already in Mercurial), I haven't found a real solution.
Has it happened to you before? How did you solve it? Please, help me. It works just fine on my desktop (Windows) machine, but sometimes I need to make modifications while I'm away, and this is driving me crazy.
Thanks in advance!
When I issue the locale command on my mac osx, I get the following
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
For you it should be
LANG=es_ES.UTF-8
LC_ALL=es_ES.UTF-8
Are you exporting these? Because, your locale should have shown a different value after exporting.
export LC_ALL=es_ES.UTF-8
export LANG=es_ES.UTF-8
Your Spanish locale should be es_ES.UTF-8 (if your terminal does use UTF-8), or es_ES (which will use ISO-8859-1 encoding). "C" locale knows nothing about Spanish accentend characters.
Anyway, if properly setting locale in your terminal doesn't help, then you can try setting
[ui]
fallbackencoding=ISO-8859-1
in your .hgrc config file.
No idea what really happened. I deleted any file I had of Mercurial from my compilation, and just used the installation package.
Yes, it now works wonders. Thank you all!
What's the best way to go about making a patch for a binary file?
I want it to be simple for users to apply (a simple patch application would be nice). Running diff on the file just gives Binary files [...] differ.
Check out bsdiff and bspatch (website, manpage, paper, GitHub fork).
To install this tool:
Windows: Download and extract this package. You will also need a copy of bzip2.exe in PATH; download that from the "Binaries" link here.
macOS: Install Homebrew and use it to install bsdiff.
Linux: Use your package manager to install bsdiff.
Courgette, by the Google Chrome team, looks like most efficient tool for binary patching executables.
To quote their data:
Here are the sizes for the recent 190.1 -> 190.4 update on the developer channel:
Full update: 10,385,920 bytes
bsdiff update: 704,512 bytes
Courgette update: 78,848 bytes
Here are instructions to build it. Here is a Windows binary from 2018 courtesy of Mehrdad.
xdelta (website, GitHub) is another option. It seems to be more recent, but otherwise I have no idea how it compares to other tools like bsdiff.
Usage:
Creating a patch: xdelta -e -s old_file new_file delta_file
Applying a patch: xdelta -d -s old_file delta_file decoded_new_file
Installation:
Windows: Download the official binaries.
Chocolatey: choco install xdelta3
Homebrew: brew install xdelta
Linux: Available as xdelta or xdelta3 in your package manager.
Modern port: Very useful .NET port for bsdiff/bspatch:
https://github.com/LogosBible/bsdiff.net
My personal choice.
I tested it, and it was the only one of all links. Out of the box I was able to compile it (with Visual Studio, e.g., Visual Studio 2013). (The C++ source elsewhere is a bit outdated and needs at least a bit polishing and is only 32 bit which sets real memory (diff source size) limits. This is a port of this C++ code bsdiff and even tests if the patch results are identical to original code.)
Further idea: With .NET 4.5 you could even get rid of the #Zip library, which is a dependency here.
I haven't measured if it is slightly slower than the C++ code, but it worked fine for me, (bsdiff: 90 MB file in 1-2 minutes), and time-critical for me is only the bspatch, not the bsdiff.
I am not really sure, if the whole memory of a x64 machine is used, but I assume it. The x64 capable build ("Any CPU") works at least. I tried with a 100 MB file.
-
Besides: The cited Google project 'Courgette' may be the best choice if your main target are executable files. But it is work to build it (for Windows measures, at least), and for binary files it is also using pure bsdiff/bspatch, as far as I have understood the documentation.
For small, simple patches, it's easiest just to tell diff to treat the files as text with the -a (or --text) option. As far as I understand, more complicated binary diffs are only useful for reducing the size of patches.
$ man diff | grep -B1 "as text"
-a, --text
treat all files as text
$ diff old new
Binary files old and new differ
$ diff -a old new > old.patch
$ patch < old.patch old
patching file old
$ diff old new
$
If the files are the same size and the patch just modifies a few bytes, you can use xxd, which is commonly installed with the OS. The following converts each file to a hex representation with one byte per line, then diffs the files to create a compact patch, then applies the patch.
$ xxd -c1 old > old.hex
$ xxd -c1 new > new.hex
$ diff -u old.hex new.hex | grep "^+" | grep -v "^++" | sed "s/^+//" > old.hexpatch
$ xxd -c1 -r old.hexpatch old
$ diff old new
$
This is a simpler, cleaner, better version suggested by bmaupin that uses process substitution instead of intermediate files, diff, and grep:
$ comm -13 <(xxd -c1 old) <(xxd -c1 new) > old.hexpatch
$ xxd -c1 -r old.hexpatch old
$ diff old new
$
Here the comm -13 removes lines that appear only in the first input as well as lines that appear in both inputs, leaving only the lines exclusive to the second input.
HDiffPatch can run on Windows, macOS, Linux, and Android.
It supports diffs between binary files or directories;
Creating a patch: hdiffz [-m|-s-64] [-c-lzma2] old_path new_path out_delta_file
Applying a patch: hpatchz old_path delta_file out_new_path
Install:
Download from last release, or download the source code & make;
Jojos Binary Diff is another good binary diff algorithm;
diff and git-diff can handle binary files by treating them as text with -a.
With git-diff you can also use --binary which produces ASCII encodings of binary files, suitable for pasting into an email for example.
https://github.com/reproteq/DiffPatchWpf
DiffPatchWpf
DiffPatchWpf simple binary patch maker tool.
Compare two binary files and save the differences between them in new file patch.txt
Apply the patch in another binary fast and easy.
Now you can apply the differences in another binary quickly and easily.
example:
1- Load file Aori.bin
2- Load file Amod.bin
3- Compare and save Aori-patch.txt
4- Load file Bori.bin
5- Load patch Aori-patch.txt
6- Apply patch and save file Bori-patched.bin
alt tag
https://youtu.be/EpyuF4t5MWk
Microsoft Visual Studio Community 2019
Versión 16.7.7
.NETFramework,Version=v4.7.2
Tested in windows 10x64bits
Assuming you know the structure of the file you could use a C / C++ program to modify it byte by byte:
http://msdn.microsoft.com/en-us/library/c565h7xx(VS.71).aspx
Just read in the old file, and write out a new one modified as you like.
Don't forget to include a file format version number in the file so you know how to read any given version of the file format.