Message ID | 20200619175601.569856-1-sandals@crustytoothpaste.net (mailing list archive) |
---|---|
Headers | show |
Series | SHA-256 part 2/3: protocol functionality | expand |
"brian m. carlson" <sandals@crustytoothpaste.net> 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.
On 2020-06-19 at 21:09:33, Junio C Hamano wrote: > "brian m. carlson" <sandals@crustytoothpaste.net> writes: > > > 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. Okay, sorry about that. It does make it more convenient for me eventually (since I get to resolve conflicts more incrementally), but I don't usually have to worry about that until the series hits master, so I can hold off. I'm not rebasing as many patches anymore, so it's less of a problem for me. > 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. Yeah, I discovered it the other day when updating another project to deal with a SHA-256 Git, and I happen to be on vacation today, so I thought I'd send out a quick fix. I was surprised to learn that we had no tests for cloning empty repositories, but here we are.