Is there any equivalent for "git log --grep="STRING" in windows?
I've written a python program for linux which requires a reading of commit logs that contain certain string from the git object. This worked fine in linux, but when I ran the same program in windows, git log --grep="STRING" catches nothing.
Here's the code snippet. (fetcher.py)
import os
...
os.chdir(DIRECTORY) # where git obj is
command = "git log --all --grep='KEYWORD' > log.txt"
os.system(command) # run the command in the shell
...
It seems that git internally uses the linux grep for the "--grep" argument such that Windows cannot run this correctly as it misses grep.
Thanks for your help.
As I am not getting any answer for 24 hrs,
I suggest my own solution, which does not utilize grep.
Because git log itself runs without any problem,
I just ran the command without the --grep='STRING' option, then read the output from the shell (or a file) to filter the commit logs which contain 'STRING' by the use of regular expression.
import os
import re
command = "git log --all > log.txt"
os.system(command) # run the command in the shell and store output in log.txt
with open('log.txt', 'r') as fp:
gitlogoutput = fp.readlines() # read the redirected output
if gitlogoutput:
commits = re.split('[\n](?=commit\s\w{40}\nAuthor:\s)', gitlogoutput)
# it splits the output string into each commits
# at every '\n' which is followed by the string 'commit shahash(40bytes)\nAuthor: '
for commit it commits:
if 'KEYWORD' is in commit:
print commit
The approach requires you to add some code, but I believe it does the same thing as the original command does. For better results, you can change the last if statement which is,
if 'KEYWORD' is in commit:
into something that can do more sophisticated search e.g. re.search() method.
In my case, this produced exactly the same result as that of --grep="KEYWORD"
Still, I appreciate your help :)
It seems that git internally uses the linux grep for the "--grep" argument such that Windows cannot run this correctly as it misses grep.
It certainly can, provided your %PATH% includes <git>/usr/bin (which has 200+ Linux commands compiled for Windows)
See this simplified path:
set G=c:\path\to\latest\git
set PATH=%G%\bin;%G%\usr\bin;%G%\mingw64\bin
set PATH=%PATH%;C:\windows\system32;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\
Add the PATH for python, and you can "Linux grep" without any issue.
In Windows, use the following format (replacing the = sign with a space):
git log --grep "STRING"
Related
I am trying to run a sh file on git bash on Windows 10. I am even seeing the statements which I don't want to be shown like variable assignment in the console. But the same stuff I can't see on either Windows Subsystem for Linux(WSL) or other linux distributions. It becomes a bit annoying to see all the code lines in the sh file when trying to run that, when I am only interested in seeing the statements which I want to echo. Can someone please help in this ?
Sample sh file :
#!/usr/bin/env sh
VARIABLE="OK"
echo $VARIABLE
Output on git bash:
Output on WSL(or any other Linux Systems):
That only happens when both of these occur:
set -x is used
PS4 is set
If you fix either one, the messages will go away.
If you want to fix number one, you can do set +x, or you can find the file that
is calling set -x and remove that line. Probably ~/.bash_profile or
~/.bashrc.
If you want to fix number two, you can do PS4=, and you can add it to one of
those files above to persist if you want.
I need some help adding arguments to the Git difftool.
I have Beyond Compare (BC) configured as a diff tool for Git. If I invoke the following line, Beyond Compare will successfully open with a diffed file:
git difftool
What I would like to do is invoke a Beyond Compare diff from Git Bash but using the command-line arguments Beyond Compare allows. For example, I'd like to set the report file BC uses to dictate the output format. I'd also like to dictate the output file, while hopefully dictating that the output file contains a filename similar to the file being compared, such as .html.
BC's command line form is: BC /silent
Any suggestions on how I can get the diff tool to do something like:
git difftool
Thanks!!
I am trying to get some information about some git commits via the command line as part of a larger automated tool I am building. The information I want is available via this git log command:
git log --branches --graph --oneline --parents
which produces this output:
This is great, because this has the hashes and tags that I want, as well as the commit messages. However, when I pipe this to a file, the stuff in the brackets seems to somehow get lost. I'm not too interested in the colour, but I do want just the plain text as I would expect from any *nix-like program.
This is the output I seem to get instead, which omits some of the output I want (eg, the tag information):
I'm not sure how or why this information gets lost when being piped somewhere. I feel like this might be something incredibly simple and obvious.
I experience the same problem whether I do this in Bash on Arch Linux (with the latest version of git) or in the MINGW64 Bash environment in Windows.
Question: How can I completely capture git log's output without losing the information that is being lost when piping to a file?
You need to add the --decorate option to your log command. Set it either as --decorate=short or --decorate=full.
It appears in your config you've probably got log.decorate set to auto, which means that tags and such are displayed (in short form) when writing to the terminal, but not to a pipe or other file.
Similarly there are config values and command options that govern if (and when) color codes are output; so
git log --branches --graph --oneline --parents --decorate=short --color=always
would output the tags and colors even when redirected to a file.
Note that when scripting you should probably include these options on the command line rather than make assumptions about what config values are set. Depending on what you do with the output, log may or may not be the best command to use in scripting anyway, as git commands are somewhat divided into those meant for human consumption vs those mean for scripting.
Your git command:
git log --branches --graph --oneline --parents
does not produce the same output for me that you show in your first example. It does, however, produce output similar to the second example. The ref names in the brackets (branches and tags) are included when you add the --decorate option. (Here's the documentation.)
Note that your git log format can be controlled in your ~/.gitconfig file. For example, the format you've shown in your question looks like it might be achieved with options like this:
git log --decorate --graph --all --format='%C(auto,yellow)%h%C(auto,reset) %C(auto,yellow)%p%C(auto,reset) %C(auto,red)%d%C(auto,reset) %s %C(auto,green)%an%C(auto,reset) (%C(auto,cyan)%ar%C(auto,reset))'
If you are trying to automate things, you can specify a format that is better tuned to your requirements. Check the git documentation for pretty-formats for details. In particular, look for the %C format, and the %C(auto,…) notation, which causes colour controls to be used only if the command is run from a terminal.
If you always want to generate the colour information regardless of whether you're using git log interactively, you can remove each ocurrence of auto, in the above line (or alias).
I'm trying to issue a command that requires a line break due to a formatting restriction.
I need to commit a file to a CVS repository, but the repository has a restriction that requires a message to be included in the following format.
Change #: <number>
Description: <description>
The command used to commit the file is:
cvs commit -m "Change #: <number>\nDescription: <description>" <filename>
However when I issue the command it doesn't seem to be properly recognizing the line break and it fails saying that I gave it an invalid Change # and no Description.
How can I make it recognize the new line without it trying to issue two separate commands?
Try powershell in this format:
start-process -FilePath cvs.exe -ArgumentList "commit -m `"Change #:123 `nDescription:my description`""
I'm actually attempting to call this command from a Perl script and found an acceptable workaround. For some reason calling the command as a system command seems to fail, but if you call it using backticks it works fine.
# Fails
system 'cvs commit -m "Change #: <number>\nDescription: <description>" <filename>'
# Works
my $output = `cvs commit -m "Change #: <number>\nDescription: <description>" <filename>`
Whats funny is this difference in handling "\n" between using system commands and backticks doesn't seem to be documented anywhere.
Let's say I added two lines to the file hello.rb.
# this is a comment
puts "hello world"
If I do git diff, it will show that I added two lines.
I don't want git to show any line which is a Ruby comment. I tried using git diff -G <regular expression>, but it didn't work for me. How do I do git diff so that it won't show any Ruby comments?
One possibility would be (ab)using git's textconv filters which are applied before the diff is created, so you can even transform binary formats to get a human-readable diff.
You can use any script that reads from a file and writes to stdout, such as this one which strips all lines starting with #:
#!/bin/sh
grep -v "^\s*#" "$1" || test $? = 1
(test $? = 1 corrects the exit code of grep, see https://stackoverflow.com/a/49627999/4085967 for details.)
For C, there is a sed script to remove comments, which I will use in the following example. Download the script:
cd ~/install
wget http://sed.sourceforge.net/grabbag/scripts/remccoms3.sed
chmod +x remccoms3.sed
Add it to your ~/.gitconfig:
[diff "strip-comments"]
textconv=~/install/remccoms3.sed
Add it to the repository's .gitattributes to enable it for certain filetypes:
*.cpp diff=strip-comments
*.c diff=strip-comments
*.h diff=strip-comments
The main downside is that this will be always enabled by default, you can disable it with --no-textconv.
Git cares a lot about the data that you give to it, and tries really hard not to lose any information. For Git, it doesn't make sense to treat some lines as if they haven't changed if they had.
I think that the only reasonable way to do this is to post-process Git output, as Dogbert had already shown in his comment.