On 3/12/2020 12:39 PM, Jonathan Tan wrote:
>> Placing a reprepare_packed_git() call inside chck_connected() before
>> looping through the packed_git list seems like the safest way to
>> avoid this issue in the future. While reprepare_packed_git() does
>> another scan of the pack directory, it is not terribly expensive as
>> long as we do not run it in a loop. We check connectivity only a
>> few times per command, so this will not have a meaningful performance
>> impact. In exchange, we get extra safety around this check.
>
> This also means that check_connected() now does the equivalent of
> reprepare_packed_git() in both its branches (the rev-list one, which
> spawns a new process and thus rereads the pack directory, and the fast
> one). This will at least help callers to reason about its behavior more
> simply, so it sounds like a good change to me.
>
>> I included how I found this (integrating v2.26.0-rc0 into Scalar), but I
>> am able to reproduce it on my Linux machine using real fetches from
>> github.com. I'm not sure why I was unable to reproduce the issue in test
>> cases using the file:// URLs or the HTTP tests.
>
> If you remember how to reproduce it using real fetches from github.com,
> could you give us reproduction steps?
Sure. Run `git init`, then replace the `.git/config` file with this:
[core]
repositoryformatversion = 1
filemode = false
bare = false
logallrefupdates = true
symlinks = false
ignorecase = true
repositoryFormat = 1
[protocol]
version = 1
[remote "origin"]
url = https://github.com/derrickstolee/TreeSearch
fetch = +refs/heads/*:refs/remotes/origin/*
promisor = true
partialclonefilter = blob:none
[branch "master"]
remote = origin
merge = refs/heads/master
then run "git fetch origin". I purposefully put a very small repo that
I have laying around, but this repros with git/git.
Thanks,
-Stolee
