"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > This is part 2 of 3 of the SHA-256 work. This series adds all of the > protocol logic to work with SHA-256 repositories. > > v3 fixes a bug in patch 34 which prevented cloning an empty repository > with the dumb HTTP protocol. We look up the hash algorithm by length of > the data in the info/refs file and if we have no refs, we have no > entries. > > Previously, we just failed and complained, which isn't really helpful, > nor is it backward compatible. So now we use whatever the default is > for the current repository. That means we honor GIT_DEFAULT_HASH or git > clone -c, and default to SHA-1 otherwise. Users are encouraged to > switch to the smart protocol if they need to distinguish the remote > side's hash algorithm when the repository is empty. > > There are tests for the default hash behavior, but not for git clone -c, > because the extensions.objectformat option doesn't exist yet. I have > tested that it does indeed work, though. > > Otherwise, this series is the same as v2 except for a rebase (for my > convenience and Junio's). Not mine, though. Keeping the same base is easier to see the incremental difference. It wasn't too cumbersome to rebase back on the same base as what was queued (and the making sure the result, when merged to 'master', matches the result of applying all these patches directly on top of 'master'), though ;-) In any case, the updated step 34 made sense to me. Thanks.
