Git not working if color.ui is enabled
|Assignee:||Jean-Baptiste Barth||% Done:|
I'm using redmine trunk and git 18.104.22.168.
I started a new project, and it didn't work with a working bare repo. Then I found that webrick was outputting this error on its log:
fatal: Not a valid object name master:
with the word "*master*" highlighted in green.
So I went to the bare repo, and running "*git branch*" I saw that the green color was on the branch list too. So I disabled the ui.color locally in that bare repo using:
git config color.ui false
and now redmine sees my repo correctly.
So, I managed to fix it on the git side, but it should be good if redmine could be able to see this by itself, and fix it or warn the user.
#3 Updated by Rodrigo Toledo over 12 years ago
My guess is that the issue has to do with some kind of special characters used to put color in the terminal, and that redmine is reading from that output in order to do something with the branch name. If this guess is right, the solution should be stripping that output of any special character before using it for something.
Anyway it's just a guess, I don't know anything about the internal workings of redmine.
#4 Updated by Rodrigo Toledo over 12 years ago
Maybe something like this http://www.commandlinefu.com/commands/view/3584/remove-color-codes-special-characters-with-sed but in the context of capturing any git output
#5 Updated by Bernhard Furtmueller over 12 years ago
I had a brief look to:
It looks these commands could need additionally the "--no-color" option:
git branch --no-color
git log --no-color
git diff --no-color
git show --no-color
git blame --no-color <- I´m not sure if it´s really neccessary here, but it doesn´t hurt though.
#15 Updated by Felix Schäfer almost 12 years ago
- Target version set to 1.0.3
Eric, the fix for that is here: http://github.com/thegcat/redmine/commit/f9583578af6760377b4d46a5b5907f92c8d47e29
I don't think it's possible to selectively activate color other than shelling out to make the change, the change no activates color to
always, so if anything ever changes in the color stuff in future git versions, we should notice through the tests. If you don't want that in, just ignore the archive of the git repo.
#16 Updated by Jean-Baptiste Barth almost 12 years ago
- Status changed from New to Resolved
- Assignee set to Jean-Baptiste Barth
- % Done changed from 0 to 100
- Resolution set to Fixed
I was able to reproduce too with a recent git version (22.214.171.124) on current trunk, with
color.ui set to
always and no other color.* behavior defined (see
git config -l|grep color ; it seems git options precedence doesn't always work as you guess).
Applied Felix's patch in r4310.
#18 Updated by Jean-Baptiste Barth almost 12 years ago
- Status changed from Closed to Reopened
- Target version changed from 1.0.3 to 1.0.4
I tested it with GIT 126.96.36.199 and 1.7.1, if anyone finds a problem with a different version let us know before it's merged in stable branch.
#21 Updated by Jean-Baptiste Barth almost 12 years ago
- File failing_test_5324.txt added
git show supports it at least from 188.8.131.52.
I don't remember having found a failing test when committed it, but I found this one yesterday when investigating something else:
% RAILS_ENV=test ruby test/functional/repositories_git_controller_test.rb -n test_diff > failing_test_5324.txt 2>&1
See result attached. No output from
app/views/common/_diff partial, and when I put the debugger in the view, I saw the diff output was full of color codes.