I am working on kernel patchset rather than git stuffs. eg: this patch:1
I download this series of patch and run follow command to patch to kernel-next.
"patch -p1 < ../xxx.patch".
I get some rej files after apply patch.
Does this mean I have to cheery-pick other patch or I have to need fix those reject file one by one.
one of reject file look like
thanks!!
From the patch man page:
If patch cannot find a place to install that hunk of the patch, it
puts the hunk out to a reject file, which normally is the name of the
output file plus a .rej suffix, or # if .rej would generate a file
name that is too long (if even appending the single character # makes
the file name too long, then # replaces the file name's last
character).
The rejected hunk comes out in unified or context diff format. If the
input was a normal diff, many of the contexts are simply null. The
line numbers on the hunks in the reject file may be different than in
the patch file: they reflect the approximate location patch thinks the
failed hunks belong in the new file rather than the old one.
So essentially your patches failed to apply cleanly. Fix the lines shown in the .rej files in the original file that it failed for.
echo "this is test file" > test.txt
echo "this is testy file" > testy.txt
echo "this is test file" > test1.txt #note the extra space
diff test.txt testy.txt > diff.patch
cat diff.patch
1c1
< this is test file
---
> this is testy file
patch -p1 test1.txt diff.patch #trying to patch test1.txt with the diff
patching file test1.txt
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file test1.txt.rej
cat test1.txt.rej
***************
*** 1
- this is test file
--- 1 -----
+ this is testy file
So, in this (dumb example) case, the test1.txt.rej indicates that test1.txt needs to be fixed. You need to manually merge the changes from drm_dp_helper.c.rej file to the file that the patch program failed to apply the changes to i.e. drm_dp_helper.c, which guessing from the failed hunk in the patch is essentially deleting a bunch of arrays etc. I'm guessing your version of drm_dp_helper.c isn't at the same change version with the original patch author's base file and might have had some changes which are leading to the patch application failure.
Related
I want to be able stage specific lines of code that match a pattern (MARKETING_VERSION in my case).
I've got the awk command which will show me the lines that match the pattern MARKETING_VERSION but I don't know how to stage the lines from that result to git.
awk '/MARKETING_VERSION/{print NR}' exampleFile.txt
the result in terminal is
1191
1245
How can I use this result to stage those specific lines in that file to git?
I know you can use git add -p but I want to use this in a shell script so I need a non-interactive version.
TIA
What git add -p <file> does is, very roughly, this:
tmpfile=$(mktemp)
tf2=$(mktemp)
tf3=$(mktemp)
git diff <file> > $tmpfile
while [ -s $tmpfile ]; do
extract first diff hunk from $tmpfile to $tf2 and rest to $tf3
show you $tf2, ask if you want to include this hunk
(with options to edit the hunk, etc); repeat until ready
if you say to *add* the hunk, run git apply --cached $tf2
cat < $tf3 > $tf2
done
rm -f $tmpfile $tf2 $tf3
That is, git add -p uses git apply --cached (a specialized sub-variant of git apply --index that ignores the working tree copy of the file). The key takeaway you need, from the above, is this: There are three versions of the file!
The first one (completely ignored here) is frozen for all time and is in the HEAD commit.
The second one is in Git's index aka staging area. That's used by git diff above as the "old version".
The third one is in your working tree. That's used by git diff above as the "new version".
The patches that Git lets you take or skip are simply the result of comparing the "old" (index) and "new" (working tree) version. If you take some patch, Git updates the in-index copy by applying the patch.
Hence, if there are some set of lines in the working tree version (say, lines 100 through 110 inclusive) that you'd like to use to replace some other set of lines (say, lines 90 through 92 inclusive) in the index version, the way to construct that is:
extract the index version;
scrape out lines 1-89 from the index version; concatenate lines 100-110 from the working tree version; concatenate lines 93-end from the index version, all into a temporary file;
replace the index copy with the temporary file.
To read the index version, use git show or git cat-file -p with the name of the index version of the file. If the file's name is path/to/file, the index version's name is :path/to/file (short for :0:path/to/file: we want the copy in slot zero; there must not be a copy in slots 1, 2, or 3 so that there is a copy in slot 0; you can simply attempt to read it from slot zero, and if that fails, assume the file either isn't in the index, or is conflicted).
Reading the working tree file (some select subset of lines) is left as an exercise, as is the concatenation part, and any error checking you wish to include.
Assuming the final resulting file is in a temporary file named $tf (as a shell variable), to update the index copy, you must first make sure an appropriate blob hash ID exists:
hash=$(git hash-object -w -t blob --path="$path" -- "$tf")
for instance (this assumes you want to run the usual .gitattribute filters, if any, and know that the path is $path). Then, if that goes well, use that hash ID with git update-index:
git update-index --cacheinfo "$mode,$hash,$path"
where $mode is either 100644 or 100755 as appropriate for the file. If you don't want to change the mode, you can read the previous mode with git ls-files --cached or similar. Otherwise, provided core.fileMode is true, read the mode from the working tree copy of the file, to match the behavior of git add: convert "has any executable bit set" to 100755 and "has no executable bit set" to 100644. When core.fileMode is false—use git config --get --type bool core.filemode to read it—git add uses the existing mode for this add-patch case.)
I'm learning how to use patch, and have encountered strange behaviour when patching two directories:
original_directory contains one file (file1) containing three lines.
updated_directory contains two files: file1 with two extra lines, and an additional file2 (containing seven lines).
I issued diff -Nur original_directory/ updated_directory/ > original_directory.patch. However, when I perform the patch (patch -p0 < original_directory.patch), I get the following output:
patching file updated_directory/file1
Reversed (or previously applied) patch detected! Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file updated_directory/file1.rej
The next patch would create the file updated_directory/file2,
which already exists! Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
1 out of 1 hunk ignored
However, when I issue cd original_directory/; patch -p1 < ../original_directory.patch everything works just fine!
I'm sure that patch -p0 < original_directory.patch worked just the other day...
This behaviour is expected and usual. You patch file probably looks something like:
diff -Nur original_directory/file1 updated_directory/file1
--- original_directory/file1 2018-09-26 15:00:33.929223318 +0900
+++ updated_directory/file2 2018-09-26 15:00:41.555279201 +0900
...
...
diff -Nur original_directory/file2 updated_directory/file2
--- original_directory/file2 1970-01-01 09:00:00.000000000 +0900
+++ updated_directory/file2 2018-09-26 15:00:49.325037178 +0900
...
...
With -p1, the first component of the paths of changed files are removed, so the patch sees instructions to make changes to file2 and file1 in the current directory.
With -p0, no path components are removed from the paths, so patch sees instructions to make changes to updated_directory/file2 and updated_directory/file1, but those files already have the required changes.
I would like to write a script that restores a file, but preserving the changes that may be done after the backout file is created.
With more details: at some moment I create a backup of a file (file_orig). Do some changes to the original file as well(file_my_changes). After that, the original file can be changed again (file_additional_changes), but after the restore I want to have the backup file, plus the additional changes (file_orig + file_addtional_changes). In general backing out my changes only.
I am talking about grub.cfg file, so the expected possible changes will be adding or removing parts of a line.
Is it possible this to be done with a bash script?
I have 2 ideas:
Add some comments above the lines I am going to change, and then before the resotore if the line differ from the one from the backed out file, to read the comment, which will tell me what exactly to remove from the line;
If there is a way to display only the part of the line that differs from the file_orig and file_additional_changes, then to replace this line with the line from file_orig + the part that differs. But I am not sure if this is possible to be done at all.
Example"
line1: This is line1
line2: This is another line1
Is it possible to display only "another"?
Of course any other ideas are welcome!
Thank you!
Unclear, but perhaps if you're using a bash script you could run a diff on the 2 edited file and the last one and save that output someplace that you want to keep it? That would mean you have a copy of the changes.
Or just use git like everybody else.
One possibility would be to use POSIX commands patch and
diff.
Create the backup:
cp operational-file operational-file.001
Edit the operational file.
Create a patch from the differences:
diff -u operational-file.001 operational-file > operational-file.patch001
Copy the operational file again.
cp operational-file operational-file.002
Edit the operational file again.
Create a new patch
diff -u operational-file.002 operational-file > operational-file.patch002
If you need to recover but skip the changes from patch.001, then:
cp operational-file.001 operational-file
patch -i patch.002
This would apply just the second set of changes to the original file, as log as there's no overlap.
Consider using a version control system to keep records of the file changes. Consider using date/time stamps instead of version numbers on the file names.
I have a patch file for some software (Magento) and want to apply it to my current project.
The patch file contains also references to files in the var/packages folder which I do not want (I deleted this folder in my installation).
When applying this patch file (patch -p1 < the.patch), I get lots of warnings like:
The next patch would delete the file var/package/Foo_Bar.1.7.0.0.xml,
which does not exist! Assume -R? [n] ^C
Is there any way to tell the patch command to just ignore patches for this folder?
You can use the “filterdiff” utility – http://man.cx/filterdiff – from http://packages.debian.org/patchutils to do that.
Otherwise, just pressing Enter a lot will also help ;-)
You can use filterdiff from the patchutils package.
-x *PATTERN*, --exclude=*PATTERN*
Exclude files matching PATTERN. All other lines in the input are displayed.
So for your example
filterdiff -p1 -x 'var/packages/*' < the.patch | patch -p1
Alternatively you can manually edit the patch to remove the unwanted files, but this make take some time if it's very large.
Occasionally, we receive ZIP files from our suppliers that are seemingly corrupted. Attempting to list the contents of a ZIP will trigger an error like this:
$>unzip -qql JABL_VER_20120808_165910.zip
unzip: cannot find or open JABL_VER_20120808_165910.zip, JABL_VER_20120808_165910.zip.zip or JABL_VER_20120808_165910.zip.ZIP.
I did a quick read of the unzip man page and coded that snippet to trap the above error
EXIT=`echo $?`
case $EXIT in
> 0-1) echo "Unzip Complete.";;
> *) echo "Unzip Failed.";;
> esac
$>Unzip Failed.
It seems to work. However, there are cases like this one where the error is different:
$>unzip -qql JABL_VER_20120808_175915.zip
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of JABL_VER_20120808_175915.zip or
JABL_VER_20120808_175915.zip.zip, and cannot find JABL_VER_20120808_175915.zip.ZIP, period.
Is there a "surefire" way to trap errors like these?
PS: Not sure if matters but the ZIP files are generated on MS Windows ; We use Red Hat.
exit code 1 isn't good either,
1 one or more warning errors were encountered, but processing completed successfully anyway. This includes zipfiles
where one or more files was skipped due to unsupported compression method or encryption with an unknown password.
you should try
unzip -t zipfilename
and only accept exit code 0
why do you have so many errors? ftp'd file in text mode?