On Sun, Mar 05, 2017 at 01:45:46PM +, Ian Jackson wrote:
> brian m. carlson writes ("Re: Transition plan for git to move to a new hash
> function"):
> > Instead, I was referring to areas like the notes code. It has extensive
> > use of the last byte as a type of lookup table key. It's very
brian m. carlson writes ("Re: Transition plan for git to move to a new hash
function"):
> Instead, I was referring to areas like the notes code. It has extensive
> use of the last byte as a type of lookup table key. It's very dependent
> on having exactly one hash, since it will always want to
On Thu, Mar 02, 2017 at 06:13:27PM +, Ian Jackson wrote:
> brian m. carlson writes ("Re: Transition plan for git to move to a new hash
> function"):
> > On Mon, Feb 27, 2017 at 01:00:01PM +, Ian Jackson wrote:
> > > Objects of one hash may refer to objects named by a different hash
> > >
brian m. carlson writes ("Re: Transition plan for git to move to a new hash
function"):
> On Mon, Feb 27, 2017 at 01:00:01PM +, Ian Jackson wrote:
> > Objects of one hash may refer to objects named by a different hash
> > function to their own. Preference rules arrange that normally, new
> >
On Mon, Feb 27, 2017 at 01:00:01PM +, Ian Jackson wrote:
> I said I was working on a transition plan. Here it is. This is
> obviously a draft for review, and I have no official status in the git
> project. But I have extensive experience of protocol compatibility
> engineering, and I hope
Ian Jackson 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
6 matches
Mail list logo