p4 diff2 command output explanation - perforce

I tried p4 diff2 command. Please help me in understanding the command's output. Specifically I want to understand the lines like following
1c1
3a4,5
6a9
13a17,18
2,7d1

It's pretty typical; see https://unix.stackexchange.com/questions/81998/understanding-of-diff-output for a very similar description.
Lines which were (a)dded, (c)hanged, or (d)eleted are prefixed by these entries.
The numbers are line numbers from either the source file or the target file.
So 1c1 means that line 1 in the source was changed, resulting in line 1 in the target.
And 13a17,18 means that lines 17-18 in the target were added after line 13 in the source.
And 2,7d1 means that lines 2 through 7 in the source were deleted before line 1 in the target.

Related

How to quickly find out the changelist deleting a line

I need to find out which changelist deleted a particular line from a file. This file is regularly updated by many people. I have 2 changelist at hand, one has the line and the other does not. The problem is, there are numerous changes in between.
Any pointer is appreciated!
[UPDATE]
I found this script, http://projects.joelinoff.com/p4tools/p4-whodunit.py, but it does not work for me:
$~/tmp/p4-whodunit.py --help
: No such file or directory
$~/tmp/p4-whodunit.py //depot/mybranch/file1
: No such file or directory
Not familiar with python, not sure what to do with it.
Use "p4 annotate -a" to find out when the line was last present; the following revision is the one that removed it.
In this example, line A was added in revision 2, and removed (replaced by B) in revision 3:
C:\test\local\dvcs\i\deltas>p4 annotate -a foo
//stream/main/i/deltas/foo#3 - edit change 50625 (text)
1-1: 1:
2-2: 1: A
3-3: 1: B
So to answer the question of "in what changelist did line A get deleted?" I can do:
C:\test\local\dvcs\i\deltas>p4 annotate -a foo | grep A
2-2: 1: A
C:\test\local\dvcs\i\deltas>p4 files foo#3
//stream/main/i/deltas/foo#3 - edit change 50625 (text)
Use P4V's Timelapse View. It will show the changelist that added the line, and the changelist that deleted the line.

How to find the diff history of specific line in a file using git?

I want to find a list of history for a specific line in a file for example
file: something.txt
1/2
line 1: // change comment to 1
2/15
line 1: // change comment to 2
12/15
line 1: // change comment to 4
If I do git blame it only shows 12/15 entry, and if there is tons of commit between 2/15 and 12/15 then git log is not really useful
Can someone give me some advice?
Thanks
For your example:
git log -L 1,1:something.txt
From the documentaion
-L <start>,<end>:<file>
-L :<funcname>:<file>
Trace the evolution of the line range given by "<start>,<end>" (or the function name regex <funcname>) within the <file>. You may not give any pathspec limiters. This is currently limited to a walk starting from a single revision, i.e., you may only give zero or one positive revision arguments. You can specify this option more than once.

Is there a way to configure vimdiff to ignore whitespace on lines that have a non-whitespace diff?

When diffing two files in vim (e.g. vim -d file1 file2), I want all whitespace to be ignored.
I almost achieved this by following the advice of Adam Katz in this question:
Is there a way to configure vimdiff to ignore ALL whitespaces?
That advice causes the diff command to get the -w option, so that it doesn't include lines with only whitespace differences in the results.
If there's a line with both whitespace differences and non-whitespaces differences, then these are correctly returned by diff. But vim highlights the whitespace as a difference too.
E.g. If the two lines being diffed are:
File 1: a,b,c,d
File 2: a, b, c, e
Then the highlighted diff will be b, c, e instead of my desired e.
Is there any way to tell vim to ignore whitespace in its highlighting process?
I'm using vim 7.3 (gvim).
diff operates on lines, not characters or words, so -b and -w determine which lines to ignore. If a line is not ignored, which is the case whenever non-whitespace changes are involved (unless you ignore case or explicitly ignore lines matching some regex), diff will always output something like this:
1c1
< a,b,c,d
---
> a, b, c, e
Altering diffopt or even diffexpr only affects how Vim invokes diff, not how it then processes the diff it receives. Since neither -b nor -w will change the above diff, Vim will consequently display the same result. Thus what you're looking for is a way to change how exactly Vim highlights the diff it receives, which I don't believe is possible.
File 1 = f1,
File 2 = f2
What about removing the whitespace in another tempfile?
vim -c "s/\s//g" -c "wq! f2.tmp" f2
then
vimdiff f1 f2.tmp

use of sed and perl to do the word processing, copying lines from one file to another

I am new to Linux and have a challenging task.
I have 3 data files, and need to do the following:
Go to line 31 of file 1, delete it
Read 1 line from file 2 and add in place of deleted line
Go to line 97 of file 1 delete it and then read the line 1 from file 2 and add in place of that deleted line in file 1.
The thing is also important to keep the same file i.e file , it is not to be changed.
I tried different versions of sed and perl, with buffer copying tricks but was not successful.
I am open for all suggestions and request the experts to give me suggestions.
I cannot find a reference to the 3rd file in your question, but if you mean replace line number 31 of file 1 with the 1st line of file 2, and replace line number 97 of file 1 with the 2nd line of file 2:
sed -i -e '30R f2
31d;96R f2
97d' f1
The new lines are important after f2 so sed knows that it is the end of the file name.
Note that the R command is a GNU extension, it is not standard.

Resolving patch conflicts manually [duplicate]

I'm having trouble applying a patch to my source tree, and it's not the usual -p stripping problem. patch is able to find the file to patch.
Specifically, my question is how to read / interpret the .rej files patch creates when it fails on a few hunks. Most discussions of patch/diff I have seen don't include this.
A simple example:
$ echo -e "line 1\nline 2\nline 3" > a
$ sed -e 's/2/b/' <a >b
$ sed -e 's/2/c/' <a >c
$ diff a b > ab.diff
$ patch c < ab.diff
$ cat c.rej
***************
*** 2
- line 2
--- 2 -----
+ line b
As you can see: The old file contains line 2 and the new file should contain line b. However, it actually contains line c (that's not visible in the reject file).
In fact, the easiest way to resolve such problems is to take the diff fragment from the .diff/.patch file, insert it at the appropriate place in the file to be patched and then compare the code by hand to figure out, what lines actually cause the conflict.
Or - alternatively: Get the original file (unmodified), patch it and run a three way merge on the file.
Wiggle is a great tool for applying .rej files when patch does not succeed.
I'm not an expert on dealing with patch files, but I'd like to add some clarity on how to read them based on my understanding of the information they contain.
Your .rej files will tell you:
the difference between the original and the .rej file;
where the problem code starts in the original file, how many lines it goes on
for in that file;
and where the code starts in the new file, and how many lines it goes on for in that file.
So given this message, noted in the beginning of my .rej file:
diff a/www/js/app.js b/www/js/app.js (rejected hunks)
## -4,12 +4,24 ##
I see that for my problem file (www/js/app), the difference between the original (noted as a/www/js/app.js on the first line) and the .rej file (noted as b/www/js/) starts on line 4 of the original and goes on for 12 lines (the part before the comma in ## -4,12, +4,24 ## on line two), and starts on line 4 of the new version of the file and goes on for 24 lines (the part after the comma in ## -4,12, +4,24 ##.
For further information, see the excellent overview of patch files (containing the information I note above, as well as details on lines added and/or between file versions) at http://blog.humphd.org/vocamus-906/.
Any corrections or clarifications welcome of course.

Resources