git magic in contrib/bc

Michael Gmelin freebsd at grem.de
Wed Apr 28 19:45:15 UTC 2021



> On 28. Apr 2021, at 21:37, Stefan Esser <se at freebsd.org> wrote:
> 
> Am 28.04.21 um 20:44 schrieb Michael Gmelin:
>> 
>> 
>>> On Wed, 28 Apr 2021 20:00:38 +0300
>>> Yuri Pankov <yuripv at ftml.net> wrote:
>>> 
>>> Not sure if it's just me, but I'm seeing a bit of git weirdness in
>>> contrib/bc:
>> 
>> I'm seeing the same here, also when doing:
>> 
>>  rm .git/index
>>  git reset
>>  git status
>> 
>> after this, `git diff' also shows what changed in those files (basically
>> every line). It's all whitespace characters, as `git diff -w' is empty.
>> 
>> Turns out EOLs changed, I suspect this is due to the eol overrides in
>> contrib/bc/.gitattributes. If I comment those out, "git diff" is silent
>> again.
> 
> Yes, the new file .gitattributes has recently been committed by me
> as part of an upgrade.
> 
> I do assume that the files affected are only for the Windows build
> that has been added in version 4.0.0.
> 
> I do not know how to fix this problem (and whether this is just a
> nuisance or an actual problem).
> 

https://git-scm.com/docs/gitattributes says:
“ eol
This attribute sets a specific line-ending style to be used in the working directory. It enables end-of-line conversion without any content checks, effectively setting the text attribute. Note that setting this attribute on paths which are in the index with CRLF line endings may make the paths to be considered dirty. Adding the path to the index again will normalize the line endings in the index.”

Without completely understanding the problem, I would suggest to try the following:

   rm .git/index
   git reset
   git commit -a
   git push

(this should re-add the files to the index using the correct attributes)

Best,
Michael

> The upstream repository is https://git.yzena.com/gavin/bc and I have
> performed a "diff -r" of the distfile of the math/gh-bc port against
> the files in vendor/bc in our repository (before the commit to that
> repository) and thus any change that we locally apply will need to
> be upstreamed.
> 
> Regards, STefan
> 


More information about the freebsd-current mailing list