Re: git magic in contrib/bc

From: Michael Gmelin <freebsd_at_grem.de>
Date: Thu, 29 Apr 2021 14:55:39 +0200
On Wed, 28 Apr 2021 21:45:03 +0200
Michael Gmelin <freebsd_at_grem.de> wrote:

> > 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
> 

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)
> 
> 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.
> > 

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=a0358e3d5184950b4316f105eb292cbafdea208b

-- 
Michael Gmelin
Received on Thu Apr 29 2021 - 10:56:03 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:28 UTC