I have a very big patch and I want to remove from it all the hunks relative to a certain path.
For example, consider the following patch:
diff -ru a/foo/1.txt b/foo/1.txt
--- a/foo/1.txt 2017-07-19 11:26:26.603140163 +0200
+++ b/foo/1.txt 2017-07-19 11:27:15.499145952 +0200
## -1 +1 ##
-1111
+11111
diff -ru a/foo/bar/3.txt b/foo/bar/3.txt
--- a/foo/bar/3.txt 2017-07-19 11:26:51.771143040 +0200
+++ b/foo/bar/3.txt 2017-07-19 11:27:23.419146966 +0200
## -1 +1 ##
-3333
+33333
diff -ru a/foo/bar/test/4.txt b/foo/bar/test/4.txt
--- a/foo/bar/test/4.txt 2017-07-19 11:29:38.599167147 +0200
+++ b/foo/bar/test/4.txt 2017-07-19 11:29:43.655167998 +0200
## -1 +1 ##
-4444
+44444
I would like to remove from the patch all the changes relative to the path foo/bar, so that it would become:
diff -ru a/foo/1.txt b/foo/1.txt
--- a/foo/1.txt 2017-07-19 11:26:26.603140163 +0200
+++ b/foo/1.txt 2017-07-19 11:27:15.499145952 +0200
## -1 +1 ##
-1111
+11111
Is there any way I can use diff, patch, quilt or any other tool to do that?
filterdiff it the definitive tool!
filterdiff -p1 -x foo/bar/* my.patch
Related
I'm working in a project that uses buildroot-2012.11 to generate a Linux image for an embedded system.
I need to configure openocd for a JTAG debugger that uses an FTDI chip (FT2232D).
I realized that this buildroot version integrate openocd-0.5.0 and the latest openocd release is 0.9.0. I'm interested in updating to this version since I want to use ftdi interface driver instead of ft2232 (deprecated).
I tried to accomplish that by modifying /package/openocd/openocd.mk on the lines:
OPENOCD_VERSION:=0.9.0
OPENOCD_CONF_OPT += --enable-ftdi
The new openocd files where downloaded successfully but when it tries to install it and apply openocd-0001-fix-cross-compilation-host-libsub-was-used-before.patch I got:
Applying openocd-0001-fix-cross-compilation-host-libsub-was-used-before.patch using patch:
can't find file to patch at input line 17
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|From 3728c4af7f6303ccedab56ec220797f8f290580e Mon Sep 17 00:00:00 2001
|From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj#jcrosoft.com>
|Date: Wed, 10 Aug 2011 00:17:29 +0800
|Subject: [PATCH] fix cross compilation: host libsub was used before
|
|tested in buildroot
|
|Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj#jcrosoft.com>
|---
| configure.in | 7 +++++--
| 1 files changed, 5 insertions(+), 2 deletions(-)
|
|diff --git a/configure.in b/configure.in
|index dfa1e8f..cfe2218 100644
|--- a/configure.in
|+++ b/configure.in
--------------------------
File to patch: configure.in
configure.in: No such file or directory
If I skipped the patch the building process stop and I'm not able to generate the images.
I've doing some research on the internet and I couldn't find how to do this correctly.
Maybe one obvious solution could be updating the buildroot version but since there is a lot of other people development with the current version I'm not in a position of taking that decision right now.
I'll do appreciate any help.
Upgrade your Buildroot release. 2015.08 already has OpenOCD 0.8.0 and it should be trivial to update to 0.9.0. Plus you will benefit from the numerous improvements and updates that have been made between 2012.11 and 2015.08.
So somebody on our team moved an entire folder into a subdirectory without using hg's rename feature. The directory structure is like we need it, but the history is now gone prior to the move. It shows it as a new file when the move occurred. Numerous large merges have happened since then, and so it is not really practical to go back in time and do it right.
I have tried hg log --follow and it does not help, since hg does not know about the rename. Is there any way to manually link the files to the old removed versions after the fact, or is there some facility like the way git can infer moves and renames based on hueristics? It would be nice if there was some way to explicitly say, "this file is a continuation of this old deleted file.", even though that would still take some time to fix it all up right.
We have all but given up on ever getting that history back, but it would be really nice to have it.
You need to redo the move correctly by explicitly telling Mercurial what files were moved, then merge the broken changesets. This way you will restore the history path to the original files.
Steps, assuming <x> is the move revision, and <y> is the current head revision.
Update to the revision before the move: hg update <x-1>
Redo the move, but now correctly using hg rename or hg rename --after
Commit
Merge with the original move revision (hg merge <x>), this should have no conflicts but if there are discard all changes.
Commit
Merge with the remaining changesets after the move (if any) (hg merge <y>)
Commit
Here is the basic process shown on the command line:
$ mkdir move-merge-test
$ cd move-merge-test
$ hg init
$ echo "x" > a
$ hg add a
$ hg commit -m "initial revision"
Move incorrectly:
$ mv a b
$ hg remove a
$ hg add b
$ hg status --copies
A b
R a
$ hg commit -m "incorrect move"
$ hg log --follow b
changeset: 1:b22f3e94133b
tag: tip
user: Laurens Holst <...>
date: Wed Oct 19 14:41:37 2011 +0200
summary: incorrect move
Correct the move:
$ hg update 0
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg rename a b
$ hg status --copies
A b
a
R a
$ hg commit -m "correct move"
created new head
$ hg log --follow b
changeset: 2:5deabbcb5480
tag: tip
parent: 0:b82f89f0c7d9
user: Laurens Holst <...>
date: Wed Oct 19 14:46:35 2011 +0200
summary: correct move
changeset: 0:b82f89f0c7d9
user: Laurens Holst <...>
date: Wed Oct 19 14:36:35 2011 +0200
summary: initial revision
Merge it with the broken move:
$ hg merge 1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg commit -m "merge with broken move"
$ hg log --follow b
changeset: 3:ce65fc7b35e4
tag: tip
parent: 2:5deabbcb5480
parent: 1:b22f3e94133b
user: Laurens Holst <...>
date: Wed Oct 19 14:47:13 2011 +0200
summary: merge broken branch
changeset: 2:5deabbcb5480
parent: 0:b82f89f0c7d9
user: Laurens Holst <...>
date: Wed Oct 19 14:46:35 2011 +0200
summary: correct move
changeset: 1:b22f3e94133b
user: Laurens Holst <...>
date: Wed Oct 19 14:41:37 2011 +0200
summary: incorrect move
changeset: 0:b82f89f0c7d9
user: Laurens Holst <...>
date: Wed Oct 19 14:36:35 2011 +0200
summary: initial revision
As you can see, the history now correctly shows all affected changesets. If the files are moved in several commits, the basic principle stays the same just merge across more than just 1 commit. If you have any commits made after the move, I recommend to merge them in separately (step 6 in the steps above) in order to avoid spurious conflicts.
I had good luck with this kind of thing by deleting the new (the "moved") file, then going back to a revision when the file was still in place, doing the move properly (including commit) and merging the two heads.
There's a --after option to hg rename which lets you tell Mercurial about a rename after the fact, but it has to be done before you commit the rename.
You could try doing hg convert on the repository and specify the --filemap parameter, which will let you rename a files and directories.
https://www.mercurial-scm.org/wiki/ConvertExtension#A--filemap
I'm actually trying something simple, but I get strange results:
I want to compare the current version of a file with a specific revision.
In NetBeans 6.9.1 I didn't find any such function. I can only call the history and then diff between successive revisions. Am I missing something?
I tried with the command line tool (Linux):
hg diff --rev 527 pom.xml
But I get:
diff -r 1018d7890ea1 pom.xml
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/pom.xml Sun Jan 30 22:45:28 2011 +0000
## -0,0 +1,167 ##
+
followed only by "+" lines.
How can I get the diff I want? How can I get this diff with NetBeans (or otherwise with another graphical diff tool)?
You usage of the command-line tool looks correct. However the output
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
Indicates that the file you want to diff did not yet exist in the revision you chose.
Addendum:
In the comments you mention the file was renamed and you need to use -g
You can enable -g for all diffs by adding:
[diff]
git=1
to your .hgrc file (usually located in your home directory)
hg diff -r revision1:revision2 file
Where revision1 and revision2 can be a tag, changeset etc.
By default, your revision2 should be "tip" (without quotes) if you want to compare a revision to the current one.
For example, if I have two files:
file1:
This is file 1
and file2:
This is file 2
and create patch with the following command:
diff -u file1 file2 > files.patch
result is:
--- file1 Fri Aug 13 17:53:28 2010
+++ file2 Fri Aug 13 17:53:38 2010
## -1,1 +1,1 ##
-This is file 1
+This is file 2
Then if I try to apply this patch on Solaris with patch command:
patch -u -i files.patch
it hangs on:
Looks like a unified context diff.
File to patch:
1. Is there a way to use Solaris native patch command with unified diffs?
2. Which diff format is considered most portable if it's not possible to apply unified format?
Update:
I've found answer on the first part of my question. Seems that patch on Solaris hangs if the second file (file2 in this case) exists in the same folder as the first one (file1). For example, the following quite common diff:
--- a/src/file.src Sat Aug 14 23:07:29 2010
+++ b/src/file.src Sat Aug 14 23:07:37 2010
## -1,2 +1,1 ##
-1
-
+2
will not work with quite common patch command:
patch -p1 -u -d a < file.patch
while the following diff (note second file is renamed):
--- a/src/file.src Sat Aug 14 23:07:29 2010
+++ b/src/file_new.src Sat Aug 14 23:07:37 2010
## -1,2 +1,1 ##
-1
-
+2
will work perfectly.
For the second part of my question see accepted answer below.
On Solaris /usr/bin/patch is an old version required to comply with some ancient standards.
A modern version of GNU patch is provided as /usr/bin/gpatch on Solaris 8 and later.
diff -cr old.new new.txt > patch.txt
gpatch -p0 < patch.txt
Works perfectly for me (using gpatch)
Single Unix v2 and v3 both support context diffs but not unified diffs, so for better portability you should use context diffs (-c option to diff and patch).
On older Solaris releases (pre-10, I think), you need to make sure that /usr/xpg4/bin is before /usr/bin in your $PATH, otherwise you may get compatibility versions of some utilities instead of standard ones.
I recently stumbled upon a cool feature in CVS where you can name revisions by date, e.g.:
# List changes made between the latest revision 24 hours ago and now
cvs diff -D "1 day ago"
Do any other repository systems (e.g. Git, SVN, Bazaar, Mercurial, etc.) have an option like this?
Subversion has a similar feature. For example:
svn diff -r {2010-07-31}
The syntax is explained in http://svnbook.red-bean.com/en/1.5/svn.tour.revs.specifiers.html#svn.tour.revs.dates
Mercurial has a wide range of date formats: http://www.selenic.com/mercurial/hg.1.html#date-formats, though maybe not "1 day ago".
This subversion bug report indicates that Subversion can't do it natively, but does offer a tip on using date to do it:
(2) Whilst Subversion doesn't understand -r "{3 days ago}", date can
help out there too: -r "{date -Is -d '3 days ago'}".
(answering my own question)
git log supports dates for filtering before or after given times. Example:
git log --after='july 17 2010' --before='july 31 2010'
Here's a shell script that makes it a little easier to list ranges of commits, but it also uses a terser format than git log's default:
#!/bin/sh
# git-changes
FORMAT='%cd%x09%h%n%x09%s%n'
CMD="git log --format=format:$FORMAT"
case $# in
0 )
$CMD ;;
1 )
$CMD "--after=`date -d "$1"`" ;;
2 )
$CMD "--after=`date -d "$1"`" --before="`date -d "$2"`";;
esac
Note: I wrapped the date arguments with the date command, since git treats 'July 17' as a few hours off from 'July 17 2010' for some reason.
Usage:
git-changes # Same as git log, but more terse
git-changes 'yesterday' # List all commits from 24 hours ago to now
git-changes 'jul 17' 'aug 1' # List all commits after July 17 at midnight
# and before August 1 at midnight.
Sample output of git-changes 'jul 17' 'aug 1':
Sat Jul 31 23:43:47 2010 -0400 86a6727
* Moved libcurl into project directory as static lib.
Sat Jul 31 20:04:24 2010 -0400 3a4eb10
* Added configuration file support.
Sat Jul 31 17:44:53 2010 -0400 aa2046b
* Fixed truncation bug in bit parser.
Sat Jul 17 00:10:57 2010 -0400 99e8124
* Added support for more bits.
Now, to see all changes introduced by commit 99e8124, type git show 99e8124. To see all changes since revision 99e8124 (not including that commit itself), type git diff 99e8124.