git: a0358e3d5184 - main - Synch index of contrib/bc with what is in workdir after cloning.

[Michael Gmelin]

On Thu, 29 Apr 2021 10:30:24 -0700
Cy Schubert <Cy.Schubert at cschubert.com> wrote:

> Going back in time through each daily snapshot, my April 26 0230U
> snapshot first exhibited the problem.

Yes, like I wrote, the problem was introduced in 8ea9013512 (which was
on April 26th).

If you take your snapshot from - let's say - April 27th, you can also
easily demonstrate the problem by doing:

  cp -a /usr/src /usr/srccopy
  cd /usr/src/srccopy
  git status

Or by doing:

  cd /usr/src
  rm .git/index
  git reset
  git status

or by doing:

  cd /usr/src
  touch contrib/bc/*vcx*
  git status

> 
> My remediation efforts are below:
> 
>> ...
> slippy$             
> 
> 
> There is no way to move forward except to rm (not git rm but UNIX rm)
> the files. Checkout another branch and blow away the affected branch.
> With the files physically deleted with rm(1) I could switch branches
> and blow away the affected branch. Without this extreme I can't even
> switch branches.

AFAIK there are two options forward:

1. Simply add the files that are shown as changed on your local branch
   (that's all my commit did, "git commit -a").
2. Temporarily do:
   echo "contrib/bc/bc*.vcx* -text" >>.git/info/attributes

> 
> Lucky for me this branch was a placeholder maintaining a record of
> what was installed on my laptop vs main, so it's easy to blow away
> and recreate. But for people with committed changes to a branch this
> would be a huge problem.

The two things above should work.

> 
> My other branches which I rebase much less frequently were unaffected.
> 
> 

AFAIK this only affects branches which happen to contain changes
since 8ea9013512.

If not, I'm afraid some breaking repo-surgery would be required, going
back before 8ea9013512 (just doing a revert patch won't accomplish
anything different).

-m

-- 
Michael Gmelin