I searched a lot, found that some people claimed they did that, but I can't make it to work.
How to you use WinMerge, my favorite diff tool on Windows, with Bazaar?
I know difftools plugin (shipped with Bazaar) handles this but the controller.py file doesn't list it, and I fail to see where to specify a path. Looks like it searches in PATH variable, and reports bzr: ERROR: Cannot find 'winmerge' in (long list of paths).
I tried to put a .cmd file, then a shortcut to WinMergeU.exe in Bazaar's directory, renaming accordingly (winmerge.cmd, winmerge.lnk) the register_diff_tool parameter. No more error, but nothing is launched...
So, does somebody has any success using WinMerge (or perhaps some other Windows tool) with Bazaar?
I would be interested to use it with extmerge plugin too...
EDIT After the first two answers, I tried some variants which I list here for reference. None worked:
# As suggested:
# Bad: bzr: ERROR: [Errno 22] Invalid argument: 'c:\\docume~1\\philho\\locals~1\\temp\\bzr_C:/Program Files/_Text/WinMerge/WinMergeU.exeh7angm.log'
wdiff = diff --using "C:/Program Files/_Text/WinMerge/WinMergeU.exe"
# Bad: bzr: ERROR: Cannot find 'C:Progra~1_TextWinMergeWinMergeU.exe' in <PATH>
wdiff = diff --using C:\Progra~1\_Text\WinMerge\WinMergeU.exe
# Variants:
# Bad: bzr: ERROR: [Errno 22] Invalid argument: 'c:\\docume~1\\philho\\locals~1\\temp\\bzr_C:/Progra~1/_Text/WinMerge/WinMergeU.exejuttft.log'
wdiff = diff --using C:/Progra~1/_Text/WinMerge/WinMergeU.exe
# Bad: bzr: ERROR: [Errno 22] Invalid argument: 'c:\\docume~1\\philho\\locals~1\\temp\\bzr_C:\\Program Files\\_Text\\WinMerge\\WinMergeU.exehpabjl.log'
wdiff = diff --using "C:\\Program Files\\_Text\\WinMerge\\WinMergeU.exe"
# Bad: bzr: ERROR: [Errno 22] Invalid argument: 'c:\\docume~1\\philho\\locals~1\\temp\\bzr_C:\\Progra~1\\_Text\\WinMerge\\WinMergeU.exe4gi5or.log'
wdiff = diff --using C:\\Progra~1\\_Text\\WinMerge\\WinMergeU.exe
Using:
Bazaar (bzr) 1.11
Python interpreter: C:\Program Files\_Dev\Bazaar\python25.dll 2.5.2
Actually, the awful (and embarrassing) truth is that it appears that one of my earlier attempts worked, but I saw nothing... because I was testing against a committed file! I suppose I was expecting that by default it compared last two revisions or something.
Anyway, as I wrote in a comment, I don't want to put WinMerge directory in my already too long path, so I took at middle road, making a command file and putting it in Bazaar's directory which is already in the path.
At least it works, and I can easily add parameters if needed.
[ALIASES]
wdiff = diff --using winmerge.cmd
# winmerge.cmd contains:
"C:\Program Files\_Text\WinMerge\WinMergeU.exe" %1 %2
Maybe I should put that as solution in the thread, although it lacks elegance.
For the record, while we are on the topic of external tools, I also added to bazaar.conf:
editor = C:/Program Files/_Text/SciTE/SciTE.exe
It is used by commit (without -m option), for example.
Next step: extmerge. Looking closer, it doesn't seem WinMerge is usable there, not having 3-way merge. I might use Perforce's merge, it is free and I am used to it.
Just a note for those as confused as me: extmerge isn't a GUI replacement for merge. If you run it, it will report no conflict, even if merge reports them. Actually, you have to run merge first, then extmerge to use the generated/altered files and do the job...
If you want to use WinMerge anyway, perhaps to compare OTHER to THIS, you can use:
external_merge = "C:/Program Files/_Text/WinMerge/WinMergeU.exe %o %t %r"
I hope my attempts/remarks here will be useful to some other people... :-)
[UPDATE]
Oookaaay!
So I was confused! A message in the Bazaar mailing list enlightened my poor soul:
"You know that bzr also provides diff --using, right? You prefer the version in difftools?" -- Aaron Bentley, 2009-04-03 in Re: difftools, ‘bzr diff --using footool’, and ‘diffuse’
Aargh! No, I didn't know that.
I removed difftools plugin, edited my line to:
wdiff = diff --using "C:/Program Files/_Text/WinMerge/WinMergeU.exe"
and it worked perfectly fine, out of the box! I am not sure why this difftools plugin isn't marked as obsolete.
I leave this question as a reference in case other newbies like me are confused too. And I can at least elect an answer. Thanks!
bzr diff --using "C:/Program Files/WinMerge/WinMergeU.exe"
You can add this to aliases in bazaar.conf
Or, if you have C:\Program Files\WinMerge in your PATH environment variable you can use it as:
bzr diff --using WinMergeU.exe
Did you read the README file that came with the difftools plugin? It explained the --using option.
Also, going by bazaar installed on my windows machine, which hasn't been updated in a while, you'll find your config file in C:\Documents and Settings\username\Application Data\bazaar\2.0\bazaar.conf
Add the following under the [ALIASES] section (adding that section if it doesn't exist):
[ALIASES]
gdiff = diff --using C:\Progra~1\WinMerge\WinMergeU.exe
Change the path to suit your installation. Then you can just go
bazaar gdiff
instead of
bazaar diff
This seemed to work for me:
bzr diff --using "C:\\program files\\winmerge\\winmergeu.exe"
As an aside, if you can't get it working, I would suggest using the q* UI tools, like:
bzr qdiff
bzr qlog
bzr qcommit
..etc
The Tortoise Bazaar->Settings->General Bazaar Options->Diff->Add not works for me. I try to use the answers above, but unfortunately they not works too. But I used the answers for a base, and I find a solution. I edited the
C:\Documents and Settings\*username*\Application Data\bazaar\2.0\qbazaar.conf (not bazaar.conf)
and added the line
[EXTDIFF]
WinMerge = "C:/Program Files/TC UP/PLUGINS/Media/WinMerge/WinMergeU.exe"
It works fine, and I can choose between the builtin diff and the WinMerge.
Related
When running srb init in a Rails app I get the following:
Generating /tmp/d20220723-3779490-paqj5l/reflection.rbi with 6784 modules and 142 aliases
Printing your code's symbol table into /tmp/d20220723-3779490-paqj5l/from-source.json
/home/allan/.asdf/installs/ruby/3.1.0/lib/ruby/gems/3.1.0/gems/sorbet-0.5.10206/lib/hidden-definition-finder.rb:123:in `write_constants': Your source can't be read by Sorbet. (RuntimeError)
You can try `find . -type f | xargs -L 1 -t bundle exec srb tc --no-config --isolate-error-code 1000` and hopefully the last file it is processing before it dies is the culprit.
If not, maybe the errors in this file will help: /tmp/d20220723-3779490-paqj5l/from-source.json.err
When I check that error file I find this:
Exception::raise(): Unimplemented Parser Node: EmptyElse
Is there a workaround to get past this error?
Anytime you see Exception::raise in a Sorbet error message, it means there was a bug in Sorbet. You can report Sorbet bugs at https://github.com/sorbet/sorbet/issues
I have created a fix for this bug here: https://github.com/sorbet/sorbet/pull/6161
It will require upgrading Sorbet before you can take advantage of the fix. If you can't wait for that, you will have to hunt down the file in your codebase that uses Ruby's new case ... in syntax for pattern matching with an empty else keyword, and either delete the else keyword or change it to mention else nil instead.
Sorry for the inconvenience.
In the future, please use https://github.com/sorbet/sorbet/issues to report all issues—I only happened to see this by accident today, but I normally do not monitor StackOverflow for bug reports.
By default, IntelliJ Idea will insert (something like) the following as the header of a new source file:
/**
* Created by JohnDoe on 2016-04-27.
*/
The corresponding template is:
/**
* Created by ${USER} on ${DATE}.
*/
Is it possible to update this template so that it inserts the last date of modification when the file is changed? For example:
/**
* Created by JohnDoe on 2016-03-27.
* Last modified by JaneDoe on 2016-04-27
*/
It is not supported out of the box. I suggest you do not include information about author and last edit/create time in file at all.
The reason is that your version control system (Git, SVN) contains the same information automatically. So the manual labelling is just duplicate of already existing info, but is only more error prone and needs to be manually updated.
Here's a working solution similar to what I'm using. Tested on mac os.
Create a bash script which will replace first occurrence of Last modified by JaneDoe on $DATE only if the exact value is not contained in the file:
#!/bin/bash
FILE=src/java/test/Test.java
DATE=`date '+%Y-%m-%d'`
PREFIX="Last modified by JaneDoe on "
STRING="$PREFIX.*$"
SUBSTITUTE="$PREFIX$DATE"
if ! grep -q "$SUBSTITUTE" "$FILE"; then
sed -i '' "1,/$(echo "$STRING")/ s/$(echo "$STRING")/$(echo "$SUBSTITUTE")/" $FILE
fi
Install File Watchers plugin.
Create a file watcher with appropriate scope (it may be this single file or any other scope, so that any change in project's source code will update modified date or version etc.) and put a path to your bash script into Program field.
Now every time the file changes the date will update. If you want to update date for each file separately, an argument $FilePath$ should be passed to the script.
This might have been just a comment to #oleg-mikhailov excellent idea, but the code snippet won't fit. Basically, I just tweaked his solution.
I needed a slightly different syntax but that's not the issue. The issue was that when the script ran automatically upon file save using the File Watchers plugin, if ran on a file which doesn't include PREFIX it would run over and over for ever.
I presume the that the issue is with the plugin itself, as it didn't happen when run from the shell, but I'm not sure why it happened.
Anyway, I ended up running the following script (as I said only a slight change with respect to the original). The new script also raises an error if the the prefix doesn't exist. For me this is a feature as Pycharm prompts me with the error, and I can fix the file.
Tested with PyCharm 2021.2.3 on macOS 11.6.
#!/bin/bash
FILE=$1
DATE=`date '+%Y-%m-%d'`
PREFIX="last_modified_date: "
STRING="$PREFIX.*$"
SUBSTITUTE="$PREFIX$DATE"
if ! grep -q "$SUBSTITUTE" "$FILE"; then
if grep -q "$PREFIX" "$FILE"; then
sed -i '' "s/$(echo "$STRING")/$(echo "$SUBSTITUTE")/" $FILE
else
echo "Error!"
echo "'$PREFIX' doesn't appear in $FILE"
exit 1
fi
fi
PHPStorm has not a "hook" for launching task after detect a change in file (just for uploading in server yes). Code templating is based on the creation of file not change.
The behaviour you want (automatic change file after manual change file) can be useful for lot of things but it's circular headhache for editor. Because if you change a file it must change file (and if a file is change ? it change file ?).
However, You can, perhaps, "enable Live Templates" when you launch a "reformat code" which able to rewrite your begin template code that way rewrite date modification.
Other solution is that use a tools with as grunt but I don't know if manage php file.
When I try to compile nettle-2.7.1, I get the following:
root#tcx2270-19:~/nettle-2.7.1# make
make: Warning: Can't find aes-decrypt-internal.o.d': No such file or directory
make: Fatal error in reader: Makefile, line 594: Read of include fileaes-decrypt-internal.o.d' failed
Has anyone seen this issue? Thanks.
I also had the exact same problem. It has nothing to do with gmp. The ./configure script generates a broken Makefile. After doing some analyzation of the generated Makefile I figured out a solution.
On the very bottom of the generated Makefile search for the line that looks like the following:
DEP_FILES = $(SOURCES:.c=.$(OBJEXT).d) $(SOURCES:.c=.p$(OBJEXT).d) asm.d
You can fix the build by changing it to the following line:
DEP_FILES = $(SOURCES:.c=.c.$(OBJEXT).d) $(SOURCES:.c=.c.p$(OBJEXT).d) asm.d
Additionally, we have to fix the Makefiles in all sub-directories.
For ./tools/Makefile, on the very bottom, find the line that looks like:
include $(SOURCES:.c=.$(OBJEXT).d)
and change it to
include $(SOURCES:.c=.c.$(OBJEXT).d)
Furthermore, you need to add the following two build-targets:
../libnettle.a:
$(MAKE) -C .. libnettle.a
../libhogweed.a:
$(MAKE) -C .. libhogweed.a
For ./testsuite/Makefile, on the very bottom, find the line that looks like this:
DEP_FILES = $(SOURCES:.c=.$(OBJEXT).d) $(CXX_SOURCES:.cxx=.$(OBJEXT).d)
and change it to:
DEP_FILES = $(SOURCES:.c=.c.$(OBJEXT).d) $(CXX_SOURCES:.cxx=.cxx.$(OBJEXT).d)
Finally, in ./examples/Makefile, again on the very bottom, search for the line that looks like:
include $(SOURCES:.c=.$(OBJEXT).d)
and change it to
include $(SOURCES:.c=.c.$(OBJEXT).d)
Phew, at least for me, that makes the build work. Of course, this is an ugly solution but it gets the job done. A better solution would be to fix the configure-script but I did not have the time to do it yet. It is also worth noting that nettle 3.0 does not have this issue. Too bad gnutls does not work with that newer version.
UPDATE: I created a patch which does all the above fixes in the Makefile.in files. As a result, you don't have to fix them yourselfs. Optimally, just unpack the source, apply the patch and proceed the way you normally would by continuing with the ./configure.
Get it from here: http://pastebin.com/36M5LHK3
So I found the question about how to view the change history of a file, but the change history of this particular file is huge and I'm really only interested in the changes of a particular method. So would it be possible to see the change history for just that particular method?
I know this would require git to analyze the code and that the analysis would be different for different languages, but method/function declarations look very similar in most languages, so I thought maybe someone has implemented this feature.
The language I'm currently working with is Objective-C and the SCM I'm currently using is git, but I would be interested to know if this feature exists for any SCM/language.
Recent versions of git log learned a special form of the -L parameter:
-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.
...
If “:<funcname>” is given in place of <start> and <end>, it is a regular expression that denotes the range from the first funcname line that matches <funcname>, up to the next funcname line. “:<funcname>” searches from the end of the previous -L range, if any, otherwise from the start of file. “^:<funcname>” searches from the start of file.
In other words: if you ask Git to git log -L :myfunction:path/to/myfile.c, it will now happily print the change history of that function.
Using git gui blame is hard to make use of in scripts, and whilst git log -G and git log --pickaxe can each show you when the method definition appeared or disappeared, I haven't found any way to make them list all changes made to the body of your method.
However, you can use gitattributes and the textconv property to piece together a solution that does just that. Although these features were originally intended to help you work with binary files, they work just as well here.
The key is to have Git remove from the file all lines except the ones you're interested in before doing any diff operations. Then git log, git diff, etc. will see only the area you're interested in.
Here's the outline of what I do in another language; you can tweak it for your own needs.
Write a short shell script (or other program) that takes one argument -- the name of a source file -- and outputs only the interesting part of that file (or nothing if none of it is interesting). For example, you might use sed as follows:
#!/bin/sh
sed -n -e '/^int my_func(/,/^}/ p' "$1"
Define a Git textconv filter for your new script. (See the gitattributes man page for more details.) The name of the filter and the location of the command can be anything you like.
$ git config diff.my_filter.textconv /path/to/my_script
Tell Git to use that filter before calculating diffs for the file in question.
$ echo "my_file diff=my_filter" >> .gitattributes
Now, if you use -G. (note the .) to list all the commits that produce visible changes when your filter is applied, you will have exactly those commits that you're interested in. Any other options that use Git's diff routines, such as --patch, will also get this restricted view.
$ git log -G. --patch my_file
Voilà!
One useful improvement you might want to make is to have your filter script take a method name as its first argument (and the file as its second). This lets you specify a new method of interest just by calling git config, rather than having to edit your script. For example, you might say:
$ git config diff.my_filter.textconv "/path/to/my_command other_func"
Of course, the filter script can do whatever you like, take more arguments, or whatever: there's a lot of flexibility beyond what I've shown here.
The closest thing you can do is to determine the position of your function in the file (e.g. say your function i_am_buggy is at lines 241-263 of foo/bar.c), then run something to the effect of:
git log -p -L 200,300:foo/bar.c
This will open less (or an equivalent pager). Now you can type in /i_am_buggy (or your pager equivalent) and start stepping through the changes.
This might even work, depending on your code style:
git log -p -L /int i_am_buggy\(/,+30:foo/bar.c
This limits the search from the first hit of that regex (ideally your function declaration) to thirty lines after that. The end argument can also be a regexp, although detecting that with regexp's is an iffier proposition.
git log has an option '-G' could be used to find all differences.
-G Look for differences whose added or removed line matches the
given <regex>.
Just give it a proper regex of the function name you care about. For example,
$ git log --oneline -G'^int commit_tree'
40d52ff make commit_tree a library function
81b50f3 Move 'builtin-*' into a 'builtin/' subdirectory
7b9c0a6 git-commit-tree: make it usable from other builtins
The correct way is to use git log -L :function:path/to/file as explained in eckes answer.
But in addition, if your function is very long, you may want to see only the changes that various commit had introduced, not the whole function lines, included unmodified, for each commit that maybe touch only one of these lines. Like a normal diff does.
Normally git log can view differences with -p, but this not work with -L.
So you have to grep git log -L to show only involved lines and commits/files header to contextualize them. The trick here is to match only terminal colored lines, adding --color switch, with a regex. Finally:
git log -L :function:path/to/file --color | grep --color=never -E -e "^(^[\[[0-9;]*[a-zA-Z])+" -3
Note that ^[ should be actual, literal ^[. You can type them by pressing ^V^[ in bash, that is Ctrl + V, Ctrl + [. Reference here.
Also last -3 switch, allows to print 3 lines of output context, before and after each matched line. You may want to adjust it to your needs.
Show function history with git log -L :<funcname>:<file> as showed in eckes's answer and git doc
If it shows nothing, refer to Defining a custom hunk-header to add something like *.java diff=java to the .gitattributes file to support your language.
Show function history between commits with git log commit1..commit2 -L :functionName:filePath
Show overloaded function history (there may be many function with same name, but with different parameters) with git log -L :sum\(double:filepath
git blame shows you who last changed each line of the file; you can specify the lines to examine so as to avoid getting the history of lines outside your function.
I have a bunch of unknown files in my Bazaar working tree that I no longer want. I can get a list of them using bzr stat, but I'd like an easy way to get rid of them. (I'd expect an option for bzr revert to do this, but I'm not finding one.)
I can always write a tiny script to parse the output of bzr stat and rm or mv the unknowns, but I thought something might already exist.
I have Bazaar (bzr) 1.13.1.
bzr clean-tree will get rid of all unknown files in a working tree. It also has switches to remove ignored files, merges backups and other types of unwanted files. See bzr clean-tree --usage for full details.
Edit to add: This is true for Bazaar 2.0.0, I'm not sure about 1.13
Made a script:
#!/usr/bin/env ruby
# Move unknown files in a Bazaar repository to the trash.
#
# Author: Benjamin Oakes
require 'fileutils'
TRASH_DIRECTORY = File.expand_path('~/.Trash/')
stdout = %x(bzr stat)
within = false
stdout.each_line do |line|
if line.match(/^unknown:$/)
within = true
next
elsif line.match(/^[a-z]+:$/i)
within = false
next
end
if within
FileUtils.move(line.match(/^\s+(.*?)$/)[1], TRASH_DIRECTORY)
end
end
I've only tested it a little, but it seems to work just fine. Please let me know if you find an issue via the comments.
On a separate topic, should I learn sed & awk? I tend to write these things using ruby -e "some ruby code".