Date: Thu, 29 Apr 2021 14:55:39 +0200 From: Michael Gmelin <freebsd@grem.de> To: Stefan Esser <se@freebsd.org> Cc: Yuri Pankov <yuripv@ftml.net>, current@freebsd.org Subject: Re: git magic in contrib/bc Message-ID: <20210429145539.73cc2fcb@bsd64.grem.de> In-Reply-To: <EC588346-BB67-44FF-B368-06E70CA44F22@grem.de> References: <2b6e40a1-9aff-d587-ddb4-60157c46f404@freebsd.org> <EC588346-BB67-44FF-B368-06E70CA44F22@grem.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 Apr 2021 21:45:03 +0200 Michael Gmelin <freebsd@grem.de> wrote: > > On 28. Apr 2021, at 21:37, Stefan Esser <se@freebsd.org> wrote: > >=20 > > =EF=BB=BFAm 28.04.21 um 20:44 schrieb Michael Gmelin: =20 > >>=20 > >> =20 > >>> On Wed, 28 Apr 2021 20:00:38 +0300 > >>> Yuri Pankov <yuripv@ftml.net> wrote: > >>>=20 > >>> Not sure if it's just me, but I'm seeing a bit of git weirdness in > >>> contrib/bc: =20 > >>=20 > >> I'm seeing the same here, also when doing: > >>=20 > >> rm .git/index > >> git reset > >> git status > >>=20 > >> 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. > >>=20 > >> 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. =20 > >=20 > > Yes, the new file .gitattributes has recently been committed by me > > as part of an upgrade. > >=20 > > I do assume that the files affected are only for the Windows build > > that has been added in version 4.0.0. > >=20 > > I do not know how to fix this problem (and whether this is just a > > nuisance or an actual problem). > > =20 >=20 > https://git-scm.com/docs/gitattributes says: > =E2=80=9C 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.=E2=80=9D >=20 > Without completely understanding the problem, I would suggest to try > the following: >=20 > rm .git/index > git reset > git commit -a > git push >=20 It is enough to touch contrib/bc/* to trigger the same behavior: Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: bc.vcxproj modified: bc.vcxproj.filters modified: bcl.vcxproj modified: bcl.vcxproj.filters > (this should re-add the files to the index using the correct > attributes) >=20 > Best, > Michael >=20 > > 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. > >=20 These files won't differ from what is checked into our repo - the problem seems only to be with the index, due to the order in which they were checked in. I simply recommitted[0] what is in the workdir after touching the files (the new modification time made "git status" consider them, they were always different after checkout than what's in .git/index). This fixes the issue we perceived (checkout, copy, touch etc. won't show the paths to be dirty anymore), while the diff to gavin/bc stays clean: $ diff -r contrib/bc ~/gavin/bc Only in /home/user/gavin/bc: .git I think this is the correct way to address the problem (having it around was definitely more than a nuisance, as it would pop up as a change every time the index is refreshed). Cheers, Michael [0]https://cgit.freebsd.org/src/commit/?id=3Da0358e3d5184950b4316f105eb292c= bafdea208b --=20 Michael Gmelin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210429145539.73cc2fcb>