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

[Michael Gmelin]

On Thu, 29 Apr 2021 19:22:22 +0300
Konstantin Belousov <kostikbel at gmail.com> wrote:

> On Thu, Apr 29, 2021 at 05:21:22PM +0200, Michael Gmelin wrote:
> > 
> > 
> ...
> 
> So I have the same, on the very living branch I rebased yesterday.
> Today I cannot:
> 
> solo% git status
> ~/work/DEV/src On branch pt_coredump
> 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/amd64/compile/
> 
> no changes added to commit (use "git add" and/or "git commit -a")
> solo% git checkout .
> ~/work/DEV/src Updated 4 paths from the index
> solo% git status
> ~/work/DEV/src On branch pt_coredump
> 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/amd64/compile/
> 
> no changes added to commit (use "git add" and/or "git commit -a")
> 
> Whatever brokeness in repo we had before, it did not prevented other
> people to work with it.  Now I cannot even rebase.

It would have in the future, as the problem is caused by switching
between branches. The moment any of those files changes, we would see
the same problem re-appear. Anytime re-indexing happens you would see
the problem re-appear. Sooner or later somebody would then commit those
files as part of another commit by accident and we are in the same
situation again.

> 
> Requiring all developers to add some attributes to all clones just
> moves the brokeness into wrong direction.

I'm happy to see a better solution applied, I don't know if there is
any that won't break rebasing for commits that happened (and that
doesn't involve going back to the offending commit and changing
history/hashes).

Even just removing the files from contrib/bc would cause these issues
when switching between branches/rebasing at this point. Essentially,
anything that involves commits since 8ea9013512 is somehow affected.
IMHO the shorter we keep this period, the better, but again, if you
have a better idea, do whatever is necessary.

-m

-- 
Michael Gmelin