newren
Fetching notes causes the fresh clone check to fail
I don't know how the heuristics for the fresh clone check work, so I don't know if this is easy or even possible; but ideally, repositories in which the only thing that has been done since cloning is fetching, should not fail the fresh clone check.
The reason is, git clone normally does not copy notes. It will if you use --mirror, but this also implies --bare, which is often not what you want. As such, it will often be necessary to perform the following after cloning:
git fetch origin refs/notes/*:refs/notes/*
Unfortunately, this causes the fresh clone check to fail.
The user is left with little or no recourse other than --force. Since this is a fairly basic use case, many users may generally always have to do this as a matter of routine. This defeats the purpose of the fresh clone check and creates a potential for data loss from user error.
(Note that to make use of the notes, you'll generally also need to use a workaround given in issue #22).
Per a suggestion from @glensc on issue #22, you can get notes into the clone at the time of cloning by using a configuration (via git config -e --global) such as:
[remote "origin"]
fetch = +refs/notes/*:refs/notes/*
fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
fetch = +refs/merge-requests/*/head:refs/remotes/origin/mr/*
This (well, just the first fetch= line should be enough) does still pass the fresh clone check.
As such, it is probably sufficient just to mention in documentation to use this approach. Although if it's easy enough to make the fresh clone check tolerate fetches without giving up accuracy, it might prevent someone from doing --force because they didn't know to or want to change their config.
Yeah, this is a fair point. I'm a bit reticent to change the fresh clone check, though. git doesn't really have a concept of a fresh clone, so I just had to list as many possible qualities as I knew about fresh clones and then check for those. Others have asked for other exceptions, and I'm worried that adding exceptions is going down a path where people who would have failed those checks but for different reasons that represent local-only data no longer get the checks and have their history rewritten and discover they want the original back.
However, adding more documentation about handling notes sounds like a reasonable thing to do. @glensc's workaround is good, you could also manually fetch the notes after cloning and then just do a simple git gc since the check that is failing is that it looks freshly packed with just a single pack file (by checking the output of git count-objects -v).
