Lets say i have a change list 1234
I want to see the details of changelists before and after 1234
Is there a command to do that?
I am new to P4 and find it not that great compared to git, basically i want to see an equivalent command in p4 for git log and see few commits before and after the commit that is of interest to me (which is equivalent to change list 1234)
Use the p4 changes command with a revision range. Revision ranges can be changelist numbers, revision numbers, dates, or labels.
C:\Perforce\workshop>p4 changes #1230,1238
Change 1238 on 2002/01/08 by richard_geiger#rmg:intjam:chinacat 'Pass a void *closure parameter '
Change 1237 on 2002/01/08 by richard_geiger#rmg:intjam:chinacat 'Experimental support for runnin'
Change 1236 on 2002/01/08 by richard_geiger#rmg:intjam:chinacat 'Prepare template for next relea'
Change 1235 on 2002/01/08 by david_abrahams#morepie 'Files not in the original Jam d'
Change 1234 on 2002/01/08 by david_abrahams#morepie 'Newly added files were missing '
Change 1233 on 2002/01/07 by jonathan_kamens#jonathan_kamens 'Update the coument documenting '
Change 1232 on 2002/01/07 by craig_mcpheeters#craig_mcpheeters-home 'Clarified the error on invalid '
Change 1231 on 2002/01/06 by craig_mcpheeters#craig_mcpheeters-home 'Oops, forgot about NT. Changed'
Change 1230 on 2002/01/06 by craig_mcpheeters#craig_mcpheeters-home 'This contains alterations to Ma'
Related
How can I diff two files but ignore all differences between comment strings. I would like to see the comments in the resulting diff, but not have the tool consider differences between comments to be real differences.
File1.py
# File 1 code
print(“code”)
print(“same code”)
print(“code”) # comment 1
File2.py
# File 2 code
print(“different code”)
print(“same code”)
print(“code”) # comment 2
When I diff file1.py and file2.py I want to be able to ignore comments, but still print them in the diff. Perhaps some command like:
diff -y file1.py file2.py -- magicRegex “#.*”
The desired output might look like:
#File 1 code # File 2 code
print(“code”) | print(“different code”)
print(“same code”) print(“same code”)
print(“code”) # comment 1 print(“code”) # comment 2
I was thinking more about this today. Ideally, there's a tool out there to do this, but if not, I think this might work, depending on how much it is worth to you to script it:
Comment-preserving diff algorithm:
1 . For file1 and file2, process them and create 2 new files for each:
i. A version of each file with the comments removed, (file1.py.nocom).
Lines containing only a comment would not be removed. Just the comment
removed. The line numbering would need to stay the same.
ii. A file containing the locations for all the comments as well as the
actual comment text. Something like:
1,1:# File 1 code
4,15:# comment 1
2. Do the diff between file1.py.nocom and file1.py.nocom, but without the -y
flag. This will be easier to parse. Even easier, use the -c flag with a
really high value. Hopefully you can get the whole file in the diff
without any missing "common" lines that way.
3. Go through the output from #2 and add back in the comments using the info
from 1.ii. I experimented with manually editing the diff from #2 and
applying it with vim, but it didn't seem to like one of the "common" lines
having a comment change. But there may be some tool that will allow you to
view it. Barring that:
4. Use the commented diff output to recreate yourself the -y flag style
output. I guess the tricky part will be determining the width of the
left side and printing out the right column. If on #2 you weren't able
to get all the common lines into the diff output using the -c flag, then
here you'll have to re-add those missing common lines.
The above won't (easily) work with docstrings, and there are probably other cases I haven't thought of. I guess it might need to be tweaked if you have additional/removal of comment lines between files as well. But there's my two cents. It seems doable, but definitely a chunk of work.
You could preprocess them with sed. You could make a wrapper that does something like:
sed -e 's/#.*$//' file1.py > file1.stripped
sed -e 's/#.*$//' file2.py > file2.stripped
diff -y file1.stripped file2.stripped
rm file1.stripped file2.stripped
This question is not a duplicate of hg log - How to get the last 5 log entries? - it is easy to apply a limit. The problem is that the log output, when limited, does not appear to always be ordered descending by log date - the behavior changes with the addition of a revset.
For example, the simple log work "as expected" and it is displays the newest five log entries.
hg log -l5
However, when using a revset the result is the oldest nodes first (as observed without -l); hence the following shows the oldest five entries which is not desired.
hg log -r "user('Me')" -l5
How can can hg log, with a revset, be instructed to order by the log date descending ("as expected") so that the limit has a predictable1 and meaningful effect?
$ hg --version
Mercurial Distributed SCM (version 3.6.1)
1 I don't consider throwing random reverse calls in a revset predictable, but if that is the "best" way..
There are a couple of options you have.
First, you can use reverse() in conjunction with your existing revset, e.g.:
hg log -r 'reverse(user("me"))' -l 5
As a shorthand, you can also use -f or --follow, which – when used in conjunction with -r – will wrap the revision in reverse(...). Example:
hg log -f -r 'user("me")' -l 5
Or you can encode the limit in the changeset, e.g.:
hg log -r 'last(user("me"), 5)'
Note that revset aliases can be useful to avoid having to type out revsets over and over. So, you can put something like this in your .hgrc:
[revsetalias]
lastby($1) = last(user($1), 5)
And then do:
hg log -r 'lastby("me")`
Important addendum answer: do not use reverse blindly for this task. While it will work in many cases, the better/reliable generic solution is to use sort, as in:
hg log -r 'sort(user("me"), "-date")' -l 5
This is because reverse does not guarantee the source set order is well-ordered - as such it may still result in final output that does not meet the requested criteria of 'newest'.
The use of sort above guarantees the behavior as it sorts by the date, descending, and then selects the top 5 per hg log's limit option.
(Otherwise, see Reimer's answer.)
I need to walk the history of Mercurial using the commandline (no GUI tools) for a single line number all the way back through history to the starting point. As an example, I used this for Git (using git blame) for line 2:
git blame -L2,2 --porcelain --incremental Filename.txt HEAD
d1b92f3a9e31ca3e3ee56f0965609314fc192f22 2 2 1 (<- the first 2 listed is the previous line number)
author Firstname Lastname
author-mail <author#domain.com>
author-time 1140197028
author-tz +0000
committer Firstname Lastname
committer-mail <author#domain.com>
committer-time 1140197028
committer-tz +0000
summary commit message here
previous 6bbaa283b326cde510ea3146a5fc6edd8956489a Filename.txt
filename Filename.txt
I need the following information:
committer/author name
previous line number
date and time
previous hash
With git blame, I can then use this information and call it again for the specific hash and previous line number, thus traversing the entire history of that line all the way back.
For Mercurial, I found hg annotate. I have the following:
hg annotate -unlcv -r tip Filename.txt | cat -n | sed -n 2,2p
2 Firstname Lastname <author#domain.com> 24741 7c36d9284795: 2: commit message here
So this is good. I can get all the information I need, including the last hash, except I'm unsure about the previous line number. The first 2 listed above in that line is from "cat", but the second 2 listed... is that the previous line number that I should be following? I want to make absolutely sure I'm following this back through history correctly.
I wanted to test what happened if I replace a variable with a different data type:
clear
input id x0
1 1
2 13
3 .
end
list
save tabA, replace
clear
input id str5 x0
1 "1"
2 "23"
3 "33"
end
list
save tabB, replace
use tabA, clear
mmerge id using tabB, type(1:1) update replace
list
The result is:
+--------------------------------------------------+
| id x0 _merge |
|--------------------------------------------------|
1. | 1 1 in both, master agrees with using data |
2. | 2 13 in both, master agrees with using data |
3. | 3 . in both, master agrees with using data |
+--------------------------------------------------+
This seems very strange to me. I expected breakdown or disagreement. Is this a bug or am I missing something?
mmerge is user-written (Jeroen Weesie, SSC, 2002).
If you use the official merge in an up-to-date Stata, you will get what you expect.
. merge 1:1 id using tabB, update replace
x0 is str5 in using data
r(106);
I have not looked inside mmerge. My own guess is that what you see is a feature from the author's point of view, namely that it's not a problem if one variable is numeric and one variable is string so long as their contents agree. But why are you not using merge directly? There was a brief period several years ago when mmerge had some advantages over merge, but that's long past. BTW, I agree in wanting my merges to be very conservative and not indulgent on variable types.
How can I query those of the labels in ClearCase with cleartool that have a specific attribute.
I can list the labels with
lstype -kind lbtype
but I'd like to get only those that have an attribute called TestAttr.
You can
first find all the version with a certain attribute
then describe those versions in order to display their respective branch
(unix syntax)
cleartool find . -version 'attype(an_attribute_name)' \
-exec 'cleartool descr -fmt "%Sn" "$CLEARCASE_XPN" '
You will still need to parse the result to extract the branch, and sort -u the result.
The OP comments:
I'd like to query the labels not the files. I have no files with that attribute
Then find is the wrong command.
The best you could do is to list all labels in a given VOB, and describe them in order to display their attribute (if they have one)
ct lstype -kind lbtype -invob vob:/avob -fmt "%n ~ %[an_attribute_name]a"
Only the lines with some value displayed after the "~" (an arbitrary separator just put here to easily distinguish the name of the label from its attribute value) are to be considered.
A label with no attribute (at least not the 'an_attribute_name' attribute) will display only its name followed by "~", without any other data after the '~'.