Hi Andy: In message <a3b39e7c-3cf2-41c6-71a4-1beabbe64...@gmail.com>, Andy Goth writes: >On 09/23/17 10:18, John P. Rouillard wrote: >> I am trying to find out when a line disappeared from a file. > >I've long wanted a reverse annotate command. Rather than show when each >line was most recently modified or added, it would show when each line >is next modified or removed. > >I haven't taken any steps toward implementation because this will be >harder to use (certainly harder to implement) than normal annotation. >Annotate works as well as it does because each revision has only one >primary predecessor, so there's no ambiguity. Reverse annotate won't >magically know the intended "next" version with which to compare. My >best guess at how to handle this is to ask for a target version, and the >path from the current version to the target version is the one along >which changes are examined.
That sounds workable. Similar to diff between two revisions. >> I am managing a configuration file and one of the config options lines >> is no longer there. [...] >> Does fossil have something like "perforce annotate -a" or "git log -S" >> or "hg grep"? > >perforce annotate -a sounds interesting. > >"All lines, including deleted lines and lines no longer present at the >head revision, are included. Each line includes a starting and ending >revision." > >https://www.perforce.com/perforce/r14.2/manuals/cmdref/p4_annotate.html > >Though I suspect it could result in an extremely messy report should the >lines be reorganized multiple times. It looks like it figures out for each line in the file what line was at that location in a prior revision. You can specify a range of revisions as well (not just a -N count). So: p4 annotate -a myfile@23,40 would just show the lines between the two revisions (@ is a way of specifying a revision range for a file). You can also do: myfile@>2017/09/03 to get all lines in revisions created since Sept 3 2017 (@> means the value is a starting point). Also this brings up an interesting point. None of annotate, blame or praise support specifying the revision of the file. I would think being able to annotate a previous version of the file would be useful. This is fossil version 2.3 [f7914bfdfa] 2017-07-21 03:19:30 UTC Usage: fossil (annotate|blame|praise) ?OPTIONS? FILENAME Output the text of a file with markings to show when each line of the file was last modified. The "annotate" command shows line numbers and omits the username. The "blame" and "praise" commands show the user who made each check-in and omits the line number. Options: --filevers Show file version numbers rather than check-in versions -l|--log List all versions analyzed -n|--limit N Only look backwards in time by N versions -w|--ignore-all-space Ignore white space when comparing lines -Z|--ignore-trailing-space Ignore whitespace at line end See also: info, finfo, timeline >Not exactly what you're asking, but you can search across many files and >many revisions of many files using the fusefs command. fossil fusefs >will make all revisions available in the filesystem so you can use >standard programs like grep to examine them. However... Ah yes. If I was working from linux that would work. >> If there is no equivalent in fossil, I am considering running: >> >> fossil finfo _filename_ > >... You'll still need a list of versions to examine, though the above >command will provide. > >> to get a list of all the revisions where the file was changed then for >> each revision: >> >> fossil --checkin _revision_ _filename_ | grep "option name" > >Assuming you meant to have a "cat" in there somewhere. Also I was >unaware the -r option could be spelled out as -checkin. Actually meant diff in there. fossil diff --checkin _revision_ _filename_ | grep "option name" so I can see what lines changed in that revision compared to the previous revision for the file. >> Anybody have any answers, thoughts, comments or quips? > >I think your cat approach is solid. Bisect could work too, though it'll >make many changes to your checkout directory. Yeah the problem with bisect is that I have to guess right on the initial revision and on every good/bad decision. If I end up making a choice that brackets a time when the file was missing the option, I can bisect the range forever and never find the deletion. Thanks for your thoughts. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
