Jeff King <peff@xxxxxxxx> writes:
> Of the two patches, I think 4447d4129d is the better approach. The
> assumption in the code seems to be that do_read_index() (and thus
> read_index_from(), etc) will set up istate->repo. That patch fixes a
> corner case where we failed to do so. And with that fix, there's no need
> for the callers to set things up ahead of time. So it covers all of
> those initializers you mentioned.
Yeah, I tend to agree that Martin's fix, which is a more focused
one, is the better approach between the two. It was merged to
the 'master' track only a few days ago.
We are at the end of the week #4 of this 12-week cycle, and we've
accumulated about two dozens of topics already on 'maint' since the
first maintenance release v2.37.1 was done, so we may have a chance
to merge Martin's fix down to 'maint' before tagging the v2.37.2
release.
One thing that may help is to add a test similar to the situation
Emily & Paul had to t7063 on top of 4447d4129d before merging it
down, perhaps?
In your reproduction, the "rm .git/index" step makes the worktree's
branch "not checked out" (the commit is empty so "worktree add" may
check out no files, and removing the index will make it as if you
did "clone --no-checkout") ...
git init repo
cd repo
git commit --allow-empty -m base
git config core.untrackedCache true
git worktree add at
rm .git/worktrees/wt/index
git gc
... but it is not something an end user is likely to do, so I am
still curious how this was triggered in real life.
Ah, OK, I think the steps can be tweaked to
git config core.untrackedCache true
- git worktree add at
- rm .git/worktrees/wt/index
+ git worktree add --no-checkout wt
git gc
i.e. (1) With "worktree add --no-checkout", there is no need to
manually remove the index file, and (2) "at" is an obvious typo of
"wt". This does not require the history to be a singleton empty
tree, either.
And that is a less implausible thing for users to be doing, but may
still not be very common. Perhaps the --no-checkout is a prelude to
set up a custom sparse checkout pattern, to avoid a wasteful full
tree checkout before doing so, or something? If that is the case,
then the above sequence becomes a very plausible thing for users to
be doing.
> Emily, Paul: I'm 99% sure this will be the case given my reproduction
> above, but if you could try reproducing the problem with the current tip
> of "master" from git.git, that would confirm the findings.
Yes, indded. That would be very helpful.
Thanks, all, for discussing the problem and its solution(s), and
thanks in advance for further testing to help the fix forward.
