git: a0358e3d5184 - main - Synch index of contrib/bc with what is in workdir after cloning.
Cy Schubert
Cy.Schubert at cschubert.com
Thu Apr 29 16:45:21 UTC 2021
In message <20210429172122.1751663f at bsd64.grem.de>, Michael Gmelin writes:
>
>
>
> On Thu, 29 Apr 2021 07:55:58 -0700
> Cy Schubert <Cy.Schubert at cschubert.com> wrote:
>
> > In message <20210429162959.16662d66 at bsd64.grem.de>, Michael Gmelin
> > writes:
> > >
> > >
> > >
> > > On Thu, 29 Apr 2021 06:53:18 -0700
> > > Cy Schubert <Cy.Schubert at cschubert.com> wrote:
> > >
> > > > In message <202104291234.13TCYk5K092776 at gitrepo.freebsd.org>,
> > > > Michael Gmelin wr
> > > > ites:
> > > > > The branch main has been updated by grembo (ports committer):
> > > > >
> > > > > URL:
> > > > > https://cgit.FreeBSD.org/src/commit/?id=a0358e3d5184950b4316f105eb292
> cba
> > > > > fdea208b
> > > > >
> > > > > commit a0358e3d5184950b4316f105eb292cbafdea208b
> > > > > Author: Michael Gmelin <grembo at FreeBSD.org>
> > > > > AuthorDate: 2021-04-29 12:29:04 +0000
> > > > > Commit: Michael Gmelin <grembo at FreeBSD.org>
> > > > > CommitDate: 2021-04-29 12:33:56 +0000
> > > > >
> > > > > Synch index of contrib/bc with what is in workdir after
> > > > > cloning.
> > > > > From a workdir perspective this should be a no-op.
> > > > > See also:
> > > > > https://lists.freebsd.org/pipermail/freebsd-current/2021-April/07
> 9569
> > > > >
> > > .htm
> > > > > l
> > > > > ---
> > > > > contrib/bc/bc.vcxproj | 554
> > > > > ++++++++++++++++++++------------------- --
> > > > > contrib/bc/bc.vcxproj.filters | 362
> > > > > +++++++++++++-------------- contrib/bc/bcl.vcxproj |
> > > > > 320 ++++++++++++------------ contrib/bc/bcl.vcxproj.filters |
> > > > > 190 +++++++------- 4 files changed, 713 insertions(+), 713
> > > > > deletions(-)
> > > >
> > > > Whatever was done here I cannot rebase from main to my local
> > > > branches. The files remain modified. The only recourse so far was
> > > > to delete the local branch and start over. I've done this to one
> > > > inconsequential branch so far but hopefully someone can suggest a
> > > > solution.
> > >
> > > Can you show an example of how this fails for you (especially the
> > > error messages)?
> >
> > slippy$ git pull -r --all
> > Fetching freebsd
> > remote: Enumerating objects: 9, done.
> > remote: Counting objects: 100% (9/9), done.
> > remote: Compressing objects: 100% (9/9), done.
> > remote: Total 9 (delta 3), reused 0 (delta 0), pack-reused 0
> > Unpacking objects: 100% (9/9), 12.42 KiB | 111.00 KiB/s, done.
> > From https://git.freebsd.org/src
> > 59b3b210a69e..d87ee7b97fe8 stable/13 -> freebsd/stable/13
> > Already up to date.
> > slippy$ git co komquats
> > Switched to branch 'komquats'
> > slippy$ git st
> > On branch komquats
> > 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: contrib/bc/bc.vcxproj
> > modified: contrib/bc/bc.vcxproj.filters
> > modified: contrib/bc/bcl.vcxproj
> > modified: contrib/bc/bcl.vcxproj.filters
> >
> > Untracked files:
> > (use "git add <file>..." to include in what will be committed)
> > sys/i386/conf/IPFILTER
> > usr.sbin/ufdformat/
> >
> > no changes added to commit (use "git add" and/or "git commit -a")
> > slippy$ git rebase main
> > error: cannot rebase: You have unstaged changes.
> > error: Please commit or stash them.
> > slippy$ git stash push -m foobar
> > Saved working directory and index state On komquats: foobar
> > slippy$ git rebase main
> > error: cannot rebase: You have unstaged changes.
> > error: Please commit or stash them.
> > slippy$ git st
> > On branch komquats
> > 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: contrib/bc/bc.vcxproj
> > modified: contrib/bc/bc.vcxproj.filters
> > modified: contrib/bc/bcl.vcxproj
> > modified: contrib/bc/bcl.vcxproj.filters
> >
> > Untracked files:
> > (use "git add <file>..." to include in what will be committed)
> > sys/i386/conf/IPFILTER
> > usr.sbin/ufdformat/
> >
> > no changes added to commit (use "git add" and/or "git commit -a")
> > slippy$ git stash push -m foobar
> > Saved working directory and index state On komquats: foobar
> > slippy$ git st
> > On branch komquats
> > 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: contrib/bc/bc.vcxproj
> > modified: contrib/bc/bc.vcxproj.filters
> > modified: contrib/bc/bcl.vcxproj
> > modified: contrib/bc/bcl.vcxproj.filters
> >
> > Untracked files:
> > (use "git add <file>..." to include in what will be committed)
> > sys/i386/conf/IPFILTER
> > usr.sbin/ufdformat/
> >
> > no changes added to commit (use "git add" and/or "git commit -a")
> > slippy$
> >
> > rm the files, switch branch to main, rebase again, remove the branch,
> > and start over was the only solution.
> >
> > So far this affected only one branch. My other branches are so far
> > unaffected.
> >
> > As no other branch is affected it appears this was local to this one
> > branch. The branch is (was) approximately four months old. Recreating
> > it, which wasn't difficult, resolved the issue.
> >
> > This is the first time I've had any git problems of this nature here
> > at FreeBSD. I've (we've) had many at $JOB because of git-lfs, causing
> > similar looking issues. But that's a whole different kettle of fish.
> > (I'm the only one at $JOB who uses git on a UNIX-like system while
> > everyone else uses Visual Studio.)
> >
> > >
> > > >
> > > > git restore the files, git rm the files, rm the files, git stash
> > > > push, all don't remove them from the branch following rebase. And
> > > > subsequent rebase to main will fail. main is ok though.
> > > >
> > > > What is it that you did to sync the index?
> > >
> > > Like in the mail thread linked in the git comment, theoretically a
> > > noop:
> > >
> > > git clone https://git@repo.freebsd.org/src.git
> > > cd src
> > > touch contrib/bc/*vcx*
> > > git commit -a
> > > git push
> > >
> > > It's a problem caused by .gitattributes being checked in after the
> > > *vcx* files were checked in (again, see the email thread and "man
> > > 1 gitattributes").
> > >
> > > If it was for me, I would remove the .gitattributes eol specs, they
> > > shouldn't be necessary for our purposes.
> >
> > It's probably growing pains.
> >
> > It appears only one branch, probably not surprisingly my most used
> > branch, was the only one affected.
> >
>
> Hi Cy,
>
> To add more details and an explanation of what you experienced:
>
> The bc*vcx* project files were first checked in on April 6th in
> 7e5c51e523, containing CRLF line breaks.
>
> Back then, the attributes were:
>
> $ git ls-files --eol contrib/bc/bc.vcxproj
> i/crlf w/crlf attr/ contrib/bc/bc.vcxproj
>
> Now, in 8ea9013512 the .gitattributes file was added, containing:
>
> *.vcxproj eol=crlf
> *.vcxproj.filters eol=crlf
> *.sln eol= crlf
>
> This implicitly changed the the files to being "text":
>
> $ git ls-files --eol contrib/bc/bc.vcxproj
> i/crlf w/crlf attr/text eol=crlf contrib/bc/bc.vcxproj
>
> But the checked-in files still had CRLF in it (which is incompatible
> with being text).
>
> This introduced problems to the repo as described in
> https://lists.freebsd.org/pipermail/freebsd-current/2021-April/079569.html
> (basically, as soon as the files are touched, they appear as changed).
>
> You can find a good description of this general problem here:
> https://marc.info/?l=git&m=154484903528621&w=2
>
> I'm not sure what a real solution to fix history would look like
> - technically I guess that the files should have been renormalized
> before committing when .gitattributes was added.
>
> As a workaround, adding this line to .git/info/attributes works:
> contrib/bc/bc*.vcx* -text
>
> This should allow you to merge your various branches without issues.
>
> Best
> Michael
>
> p.s. @Cy to demonstrate the original problem, try:
>
> git checkout a4b5f7ba3e
> touch contrib/bc/*vcx*
> git status -s
>
> This shows:
>
> $ git status -s
> M contrib/bc/bc.vcxproj
> M contrib/bc/bc.vcxproj.filters
> M contrib/bc/bcl.vcxproj
> M contrib/bc/bcl.vcxproj.filters
>
> This might look familiar to you: This is the problem you were seeing
> while rebasing - because these files were affected by my commit, the
> effect is the same as "touch contrib/bc/*vcx*" had above.
>
> When applying the workaround:
>
> echo "contrib/bc/bc*.vcx* -text" >>.git/info/attributes
>
> the problem disappears:
>
> $ git status
> HEAD detached at a4b5f7ba3e9
> nothing to commit, working tree clean
>
> Note that this is cached, so if you remove the line from
> .git/info/attributes, it stays clean until you touch the files again
> (can be quite confusing).
I blew away my branch and recreated it but luckily I have a daily ZFS
snapshot. I'll reproduce the problem using a clone.
--
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX: <cy at FreeBSD.org> Web: https://FreeBSD.org
NTP: <cy at nwtime.org> Web: https://nwtime.org
The need of the many outweighs the greed of the few.
More information about the dev-commits-src-all
mailing list