I have a single directory of depot (//depot/branch) mapped to three places in a workspace(//user_space). Output of p4 where looks like this
$ p4 where //depot/branch/README.md
-//depot/branch/README.md //user_space/branch/README.md C:\dev\branch\README.md
-//depot/branch/README.md //user_space/branch2/README.md C:\dev\branch2\README.md
//depot/branch/README.md //user_space/branch3/README.md C:\dev\branch3\README.md
What's the meaning of the leading dashed in the command output?
The documentation doesn't seem to explain that.
The doc you linked to has an example:
-//a/b/file.txt //client/a/b/file.txt //home/_user_/root/a/b/file.txt
//a/b/file.txt //client/b/file.txt /home/_user_/root/b/file.txt
which it explains thus:
This can be interpreted as saying that the first line of the client
view would have caused the file to appear in /home/user/root/a/b/file.txt,
except that it was overridden by the second mapping in the view.
More generally, a leading hyphen was used to logically remove a line in a client view specification (I no longer use perforce day-to-day so I have forgotten the right terms).
That's a minus sign (as in 3 - 2 = 1); it indicates an exclusion.
What the output is saying is:
this file isn't mapped to branch1
this file isn't mapped to branch2
this file is mapped to branch3
Related
I'm not entirely sure what sort of diff command I'd do to match what I need. But basically I have two different directories full of files that I need to compare and outline the changes of. But in one set of files they basically have a '1' at the end of the line.
An example would be if comparing these two objects
File1/1.txt
I AM IDENTICAL
File2/1.txt
I AM IDENTICAL 1
So I'd just want the diff command to leave out the '1' at the end of the line and show me the files which actually have changes. So far I came up with something like
diff file1/ file2/ -rw -I "$1" | more
but that doesn't work.
Apologies if this is an easy obvious question.
If the number of files and/or size is not that much, you can eyeball the differences and simply use vimdiff command to compare two files side by side
vimdiff File1/1.txt File2/1.txt
Otherwise, as arkascha suggested, first you need to modify your files to eliminate the ending character(s) before comparing them.
example code
diff -r -u -P a.c b.c > diff.patch
I've tried to search in man.
man says that diff -u is to unify the pattern of output, what is the meaning of that and when should we use it?
thanks a lot.
From Wikipedia (diff utility):
The unified format (or unidiff) inherits the technical improvements made by the context format, but produces a smaller diff with old and new text presented immediately adjacent. Unified format is usually invoked using the "-u" command line option. This output is often used as input to the patch program. Many projects specifically request that "diffs" be submitted in the unified format, making unified diff format the most common format for exchange between software developers.
...
The format starts with the same two-line header as the context format, except that the original file is preceded by "---" and the new file is preceded by "+++". Following this are one or more change hunks that contain the line differences in the file. The unchanged, contextual lines are preceded by a space character, addition lines are preceded by a plus sign, and deletion lines are preceded by a minus sign.
A hunk begins with range information and is immediately followed with the line additions, line deletions, and any number of the contextual lines. The range information is surrounded by double-at signs, and combines onto a single line what appears on two lines in the context format (above). The format of the range information line is as follows:
## -l,s +l,s ## optional section heading
...
The idea of any format that diff throws at you is to transform a source file into a destination file following a series of steps. Let's see a simple example of how this works with unified format.
Given the following files:
from.txt
a
b
to.txt
a
c
The output of diff -u from.txt to.txt is:
--- frokm.txt 2015-03-17 04:34:47.076997087 -0430
+++ to.txt 2015-03-17 04:35:27.872996388 -0430
## -1,2 +1,2 ##
a
-b
+c
Explanation. Header description:
--- from.txt 2015-03-17 22:42:18.575039925 -0430 <-- from-file time stamp
+++ to.txt 2015-03-17 22:42:10.495040064 -0430 <-- to-file time stamp
This diff contains just one hunk (only one set of changes to turn file form.txt into to.txt):
## -1,2 +1,2 ## <-- A hunk, a block describing chages between both files, there could be several of these in the diff -u output
^ ^
| (+) means that this change starts at line 1 and involves 2 lines in the to.txt file
(-) means that this change starts at line 1 and involves 2 lines of the from.txt file
Next, the list of changes:
a <-- This line remains the same in both files, so it won't be changed
-b <-- This line has to be removed from the "from.txt" file to transform it into the "to.txt" file
+c <-- This line has to be added to the "from.txt" file to transform it into the "to.txt" file
Here are some StackOverflow answers with really nice info about this subject:
https://stackoverflow.com/a/10950496/1041822
https://stackoverflow.com/a/2530012/1041822
And some other useful documentation:
https://linuxacademy.com/blog/linux/introduction-using-diff-and-patch/
http://www.artima.com/weblogs/viewpost.jsp?thread=164293
The term unified was made up. Better, perhaps would have been to call it "concise".
The point of diff -u is that it is a more concise representation than context diff. Quoting from the original description of Wayne Davison's posting of unidiff to comp.sources.misc (volume 14, 31 Aug 90):
I've created a new context diff format that combines the old and new chunks into
one unified hunk. The result? The unified context diff, or "unidiff."
Posting your patch using a unidiff will usually cut its size down by around
25% (I've seen from 12% to 48%, depending on how many redundant context lines
are removed). Even if the diffs are generated with only 2 lines of context,
the savings still average around 20%.
Keep in mind that *no information is lost* by the conversion process. Only
the redundancy of having multiple identical context lines. [...]
Here are some useful links:
How to read a patch or diff and understand its structure to apply it manually
What is the format of a patch file?
Not useful (and misleading)
2.2.2 Unified Format, which appears to omit attribution.
I'm in Red Hat Linux machine, need to apply inside a file the following stuff:
This is what I have:
42506F0BB83839
need to be transformed like following:
^S:CELL:42506F0BB83839.*$ WM_PLUTO
where WM_PLUTO is tab separated.
Normally I'm editing the file with vim and apply something like
:%s /^4250/\^S:CELL:lost from this point on
How to do this ?
Please note that I have multiple lines like that, all of them have fix part 42506F0BB8 and the last 4 digits will change and can't be repeated, they are not the only lines, there are others with different details.
So, need to detect all the fix part amongthe lines and aplly substitution.
Just replace "lost from this point on" with &. In the replacement, & will be replaced with whatever was matched.
:%s /^4250.*/\^S:CELL:&.*$<tab>WM_PLUTO
You can try:
sed 's/42506F0BB8..../\^S:CELL:&\.\*\$\tWM_PLUTO/' file
The title is not really specific, but I have trouble identifying the correct key words as I'm not sure what is going on here. For the same reason, it is possible that my question has a duplicate, as . If that's the case: sorry!
I have a Linux application that receive data via flat files. I don't know exactly how those files are generated, but I can read them without any problem. Those are short files, only a line each.
For test purpose, I tried to modify one of those files and reinjected it again in the application. But when I do that I can see in the log that it added a mysterious page break at the end of the message (resulting in the application not recognising the message)...
For the sake of example, let's say I receive a flat file, named original, that contains the following:
ABCDEF
I make a copy of this file and named it copy.
If I compare those two files using the "diff" command, it says they are identical (as I expect them to be)
If I open copy via Vi and then quit without changing nor saving anything and then use the "diff" command, it says they are identical (as I also expect them to be)
If I open copy via Vi and then save it without changing anything and then use the "diff" command, I have the following (I added the dot for layout purpose):
diff original copy
1c1
< ABCDEF
\ No newline at end of file
---
.> ABCDEF
And if I compare the size of my two files, I can see that original is 71 bytes when copy is 72.
It seems that the format of the file change when I save the file. I first thought of an encoding problem, so I used the ":set list" command on Vim to see the invisible characters. But for both files, I can see the following:
ABCDEF$
I have found other ways to do my test, But this problem still bugged me and I would really like to understand it. So, my two questions are:
What is happening here?
How can I modify a file like that without creating this mysterious page break?
Thank you for your help!
What happens is that Vim is set by default to assume that the files you edit end with a "newline" character. That's normal behavior in UNIX-land. But the "files" your program is reading look more like "streams" to me because they don't end with a newline character.
To ensure that those "files" are written without a newline character, set the following options before writing:
:set binary noeol
See :help 'eol'.
Let's say we have 5 patches for a file, and 4 of the patches changed the file content and add new lines. But we can still apply a single patch 5 to the git tree. Why? Since I thought the line numbers has changed, and so the line contents didn't match any more. How does git determine which line I made a change? Through the three line context of the change? I don't think it is plausible.
BTW, how to generate a number zero patch like [PATCH 0/5]? It seems format patch can only generate from 0001.
Through the three line context of the change?
This is how git apply describes it:
Ensure at least <n> lines of surrounding context match before and after each change.
When fewer lines of surrounding context exist they all must match.
So yes, even if the line numbers changed, the context is still key in determining if a patch should apply or not.
Regarding the numbering aspect, I didn't test, but see if the --start-number option of git format-patch command can help:
--start-number <n>
Start numbering the patches at <n> instead of 1.