I have a unified diff patch which patch rejects. A visual inspection of the diff file and the original code finds the code contains all text expected by the diff file in the correct location. I have tried --ignore-whitespace and -F3 for good measure but patch still fails. Does an option exist to report exactly what is causing the patch to fail?
Related
As ue4editor help mentioned below, we can use the command "-diff [options] remote local base result" to merge the conflicted file (the 2nd usage)
When I use the command line below (The "D:\fly425\Content\StarterContent\Blueprints\Blueprint_CeilingLight.uasset" is the conflict file, the other two with sha value are remote and base.)
"C:\\Program Files\\Epic Games\\UE_4.25\\Engine\\Binaries\\Win64\\UE4Editor.exe" -diff "D:\\fly425\\Saved\\Diff\\temp-7fe27617ccadc66cf8211441acc099b752087ffe-Blueprint_CeilingLight.uasset" "D:\\fly425\\Content\\StarterContent\\Blueprints\\Blueprint_CeilingLight.uasset" "D:\\fly425\\Saved\\Diff\\temp-1fbe40fd1b8e4ffdc97d624e0fc1ed0d8bfd1d0e-Blueprint_CeilingLight.uasset" "D:\\fly425\\Content\\StarterContent\\Blueprints\\Blueprint_CeilingLight.uasset"
The merge tool window of UE4Editor is show, and I can view the merge view:
But when I click the "Accpet Source" button to resolve the conflict, the window disapeared, but the conflict it still remain. Looks like the merge feature with command line is not available. Does anyone know why?
I'm looking for this answer as well. You might get more luck if you post here: https://forums.unrealengine.com/c/development-discussion/blueprint-visual-scripting/28
I have a situation where I'd like to diff two branches in Perforce. Normally I'd use diff2 to do a server-side diff but in this case the files on the branches are so large that the diff2 call ends up filling up /tmp on my server trying to diff them and the diff fails.
I can't bring down my server to rectify this so I'm looking at checking out the the content to disk and using diff on the command line to inspect and compare the content.
The trouble is: most of the files have RCS keywords in them that are being expanded.
I know can remove keyword expansion from a file by opening the files for edit and removing the -k attribute from the files in the process, but that seems a bit brute force. I was hoping I could just tell the p4 sync command not to expand the keywords on checkout. I can't seem to find a way to do this? Is it possible?
As a possible alternative solution, does anyone know if you can tell p4 diff2 which directory to use for temporary space when you call it? If I could tell it to use abundant NAS space instead of /tmp on the Perforce server I might be able to make it work.
I'm using 2010.x version of Perforce if that changes the answer in any way.
There's no way I know of to disable keyword expansion on sync. Here's what I would try:
1) Create a branch spec between the two sets of files
2) Run "p4 files //path/to/files/... | cut -d '#' -f 1 > tmp"
Path to files above should be the right hand side of the branch spec you created
3) p4 -x tmp diff2 -b
This tells p4 to iterate over the lines of text in 'tmp' and treat them as arguments to the command. I think /tmp on your server will get cleared in-between each file this way, preventing it from filling up.
I unfortunately don't have files large enough to test that it works, so this is entirely theoretical.
To change the temp directory that p4d uses just TEMP or TMP to a different path and restart p4d. If you're on Windows make sure to call 'p4 set -S perforce TMP=' to set variable for the Perforce service; without the -S perforce you'll just set it for the current user.
I found this patch on source forge (cocoa.diff), and it implies that I can patch using the cocoa.diff file. However, I can't seem to figure out how to use the .diff file.
Thanks for any help!
EDIT: I tried "patch p1 < cocoa.diff" and the output was "patch: ** Only garbage was found in the patch input." Does this mean that the .diff file is corrupt or incorrect? Also, I'm using Mac OSX 10.6.
the file cocoa.diff seems OK, however the link failed the first time I tried and returned some error HTML which indeed looks like garbage to patch. Your command seems nearly OK (lacks a dash: patch -p1 < cocoa.diff seems better).
Say I have a locally modified file my_V1 and the newer official version of the same file: V2 , but their common ancestor V1 is gone.
And I want to merge some of changes of my_V1 into V2 in order to get a my_V2, what is the common practice to diff them, review the patch, and applying the patch.
What I am doing is mostly like
diff -U V2 my_V1 > my_patch #generate a unified patch
vi my_patch #review it
patch V2 -o my_V2 -i my_patch #apply
And when I reviewing and picking lines to merge into V2, it seems I must manually specify the new position and length of every chunk, or patch simply refuse to apply it.
Is this what we have to bear when using gnu diff?
or, am I supposed to use patch and diff in another more more elegant way?
You should have a look at patchutils, especially the filterdiff command. It can be used to review a diff and keep only some changes.
I want to apply a .patch file to one file.
I placed both in the same folder and I tried this
trinity#Zion ~/Desktop $ patch -i lalala.patch
patching file install.sub
patch unexpectedly ends in middle of line
Hunk #1 FAILED at 1562.
1 out of 1 hunk FAILED -- saving rejects to file install.sub.rej
But as you see in the output, it failed. The content of install.sub.rej is basically all the code from lalala.patch
I tried similar commands but I got the same results. I guess I'm doing something wrong.
I know applying a patch is just 1 command but I'm so lost at this. If someone tells me the command or directly patches the file (and also tells me the command) thanks
original file
http://pastebin.com/raw.php?i=PKru8m5r
patch:
http://pastebin.com/raw.php?i=kkMUHtj8
Your patch command is fine. It is the patch file itself that gives the problem (at least for me (Kubuntu 11.04), as looking at the link you gave in the comment, all patch files contain the same error...?!)
To solve the problem for me, find this line in the patch file:
## -1562,6 +1562,8 ## set_timezone() {
and remove the set_timezone() { part and the error you describe is gone.
This part is showing the function where the changes are made. When looking at the patches on the page you gave in your comment, it shows that all of them contain this extra information. As far as I know (but I am not a patch guru, so please correct me) is this not accepted by the default patch command.
(Unfortunately enough, your patch still fails and the expected lines in the patch file compared to the original file do not match...)
Quite likely, the generated patch is "correct" but double-check the encode of it and be sure it's UTF-8.