The Mercurial command
hg diff > mypatchfile
compiles a "patch" file representing the differences between the working directory and the last commit. Opening this file as plain text results in a presentation of the changes that is quite difficult to read. I want to open this file in a diff tool for a clearer presentation of the differences.
I know that the diff tool kompare can do exactly this, using the command
kompare mypatchfile
But while its presentation is certainly more readable than the plain text format, I find it lacking.
I much prefer kdiff3. Can this tool open patch files? The command
kdiff3 mypatchfile
doesn't work. Instead, the patch file is just opened in plain-text format in the left panel, while the right panel is empty. But it seems that kdiff3 should be able to open patch files, because I can just write
hg extdiff -p kdiff3
and get exactly the presentation I want. However, I don't see how I can get similar results with a previously exported patch file. Any suggestions?
(I would also appreciate recommendations for other diff tools that can open and display patch files in a readable format.)
You can't do it easy (but can try to do it with some tricks for some patches)
hg extdiff -p kdiff3 does NOT visualize custom patch, but (read carefully Extdiff extension wiki) only show in dual-window mode difference between two revisions (see difference in terms) - Working Dir and parent in simplest case (and sources for diffing are full files from relevant revisions)
I think you are just tying to visualize diff output, right ? There's a tool xxdiff that might be useful with few caveats. extdiff is an external diff, that is instead of using Mercurial diff, another program is used to do the diff of two revisions. You can even use linux diff command as an extdiff for Mercurial.
I'm using TortoiseSVN 1.7 and want to create patch file between two revisions.
I've searched, but these threads How do I create a patch from diff between revisions using TortoiseSVN? Creating a patch between two revisions do not work for me, as Show changes as unified diff generates very simple file (not a patch file). Something like
Index: myfile.txt
===================================================================
I read in Viewing Differences that
If you want to see the changes made to all files in a particular
revision in one view, you can use Unified-Diff output (GNU patch
format). This shows only the differences with a few lines of context.
It is harder to read than a visual file compare, but will show all the
changes together. From the Revision Log dialog select the revision of
interest, then select Show Differences as Unified-Diff from the
context menu.
I want to create a single patch file (or many patch files according to modified files) that contains useful diff information (like the menu context TortoiseSVN -> Create patch ...)
If you use the "Show changes as unified diff" command, then TortoiseSVN shows all changes of the selected revision in a single file.
Now simply use the "File / Save as" command to save the changes to a ".patch" or ".diff" file and there you have your patch file.
Is there a program (preferably available on Cygwin) which I can use to "filter" a diff file interactively? i.e. I want something like git interactive add, except that I want to operate on a diff file. I have already discovered filterdiff, but I don't think that it supports interactive editing, only inclusion/exclusion of hunks based on a pre-defined search criteria.
My usage scenario: I have a patch in MQ, which I would like to split up per the tutorial here: https://www.mercurial-scm.org/wiki/MqTutorial#Split_a_patch_into_multiple_patches. In order to do so, I have to edit a patch file so that it includes only the (many) changes I want, and doing this manually with a text editor is kind of a pain.
Thanks!
You can probably get what you want using the record extension: https://www.mercurial-scm.org/wiki/RecordExtension
Apply the patch (but don't commit it) and then selectively commit chunk by chunk using record. You could do that with or without mq in the works.
Emacs’ diff-mode has commands to (un)apply or delete individual hunks of a diff. It also allows editing the hunks (keeping the hunk headers up to date automatically), and it has a hunk-split command that is a bit more powerful than that in git add -p.
Any tips on how to store large amounts of text, such as programming code. So I need to retain the tabs, spaces, etc?
Also how could i keep versions like say someone edits one line, i can see the changes that have been made?
That's what various revision control systems are for.
Any of git, cvs, rcs, subversion and a host of others will work.
I agree with other posters that you probably want to use what has already been done. Sometimes rolling your own can be fun.
You could write a wrapper for the command line diff utils. Each user could have their own config to choose their preferred editor. The script would made a copy of the file, so you would have an orig and new. When done editing the script would kick off a diff and store that to disk and delete the original backup of the file. This way, you would only store the latest versions plus all diffs so you can revert back and also see the changes.
I would keep a log of all diffs created and tag them in a csv with the userid of the person who modified the file and the timestamp of the modification.
I've got a file and a patch for it. I'd like to visually apply the patch, t.i. see how the changes proposed by the patch look in context, make some corrections, and save the resulting file.
What tool can do that?
Neither of the visual diff tools (i.e. meld, diffuse, diffmerge) do what I want: they don't work with patches, they merely merge whole files.
I really like Kompare. It is just a (very nice) graphical interface for diff.
http://www.caffeinated.me.uk/kompare/
sudo apt-get install kompare
Creating and applying patches
Kompare is able to create a patch file
which lists only the differences
between two compared text files A and
B. Further, Kompare can apply a patch
file which was created this way to an
original file A and, in this manner,
recompute the contents of the
corresponding file B. This is a
comfortable utility for passing a
corrected version of a file to a
friend who already has an older
version of the same file, because only
the (relatively small) patch file has
to be delivered and the receiver can
generate the corrected file by
applying the patch to the original
file.
The patches created and applied by
Kompare are compatible to patch files
generated or applied by the command
line interface diff utility, because
Kompare is in fact merely a graphical
front end to diff and the patches are
created and applied by patch, which
gets called by Kompare.
See use vimdiff with a diff file.
gvim original.file +'vert diffpa the.patch'
This will open GVim and split the window, with the original on the left and the patch applied on the right. You can then add, remove, or change hunks, and save the changes. (Well, if you want to create a new.patch you'll have to run diff again, but that's not difficult.)
You may use the emacs ediff mode.
It lets you see and validate each chunk interactively.
For what it's worth, I have this handy script in my ~/bin directory:
#!/bin/bash
if [ "$1" == "--text" ] ; then shift; fi
if diff --brief $1 $2 ; then
exit 0
else
emacs -fn 8x13bold --eval '(ediff-files "'$1'" "'$2'")'
fi
Another option: if you use Eclipse, you can generate and apply patches visually.
The idea with visual diff tools is that you can:
make a backup copy of the patched file (or a new pristine checkout of the whole tree)
apply the patch
use the visual diff tool to review the changes in context
make any desired change to the patched file within the visual diff tool.
Some tools, such as meld or diffuse will automatically diff against the previous committed version of the files.
The key insight is that you CAN apply the patch, they discard everything you don't like as long as you have a backup copy, or if you are working on a clean checkout.
If you feel more comfortable with reading and modifying unified diffs, and just want to have more context for the diff, emacs has a fairly unique feature, which is next-error-follow-mode while viewing a diff file (diff major mode). That shows the context of a diff line in the target file.
On platforms where Kompare (a fairly nice piece of software if KDE is your cup of tea), I agree that Eclipse is a great option.
I have consistently been a reluctant Eclipse user AND I am consistently impressed by how well the tools work (once the platform finally starts up).
On Fedora, I've got just about every front end installed for each of the main version control engines (SVN - also serving my Windows machines, Mercurial, git, etc.);
Meld is quite nice (no patch interface though).
Submerge works well also.
But since Eclipse does know how to apply patches and Working Copy project created itself once I figured out to create the project in the folder containing my working copy, it may become my favorite SVN front end.
I normally use GitExtensions (.NET and Mono) which also supports applying patches interactively. I hope you are already familiar with git.
Edit: Everything mentioned below this line doesn't seem to be available directly in KDiff3. And as I mentioned before: I haven't tried it yet.
GitExtension normally uses KDiff3 as diff tool, which is able to view patches.
http://kdiff3.sourceforge.net/doc/kpart.html
Using it for patches it has only a two window view, (edit) and doesn't support merging :( but it also supports 3 way diff on complete folders etc.
Actually I never tryed it with patches.
Does xxdiff do what you are looking for?
I'd use meld.
Create two copies of the files, one without and another with the patch. Use meld to compare them, and you can see exactly what the patch is changing and make changes as necessary.
Seriously, why is this so hard?