Ian Jackson <ijack...@chiark.greenend.org.uk> wrote: A few questions and one or two suggestions...
> TEXTUAL SYNTAX > ============== > > We also reserve the following syntax for private experiments: > E[A-Z]+[0-9a-z]+ > We declare that public releases of git will never accept such > object names. Instead of this I would suggest that experimental hash names should have multi-character prefixes and an easy registration process - rationale: https://tools.ietf.org/html/rfc6648 > A single object may refer to other objects the hash function which > names the object itself, or by other hash functions, in any > combination. If I understand it correctly, this freedom is greatly restricted later on in this document, depending on the object type in question. If so, it's probably worth saying so at this point. > Commits > ------- > > The hash function naming an origin commit is controlled by the hint > left in .git for the ref named by HEAD (or for HEAD itself, if HEAD is > detached) by git checkout --orphan or git init. This confused me for a while - I think you mean "root commit"? > TRANSITION PLAN > =============== > > Y4: BLAKE by default for new projects. > > When creating a new working tree, it starts using BLAKE. > > Servers which have been updated will accept BLAKE. Why not allow newhash pushes before making it the default for new projects? Wouldn't it make sense to get the server side ready some time before projects start actively using new hashes? Or is the idea that newhash upgrade is driven from the server? What's the upgrade process for send-email patch exchange? Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h punycode Fair Isle: Southwest 6 to gale 8, backing east 5 or 6, backing north 6 to gale 8 later. Rough or very rough. Rain or showers. Moderate or good.
