On Thu, May 23 2019, Jonathan Nieder wrote:
> Eric S. Raymond wrote:
>> Jakub Narebski :
>
>>> Currently Git makes use of the fact that SHA-1 and SHA-256 identifiers
>>> are of different lengths to distinguish them (see section "Meaning of
>>> signatures") in Documentation/technical/hash-functio
On May 23, 2019 17:19, Eric S. Raymond wrote:
> Jonathan Nieder :
> > Honestly, I do think you have missed some fundamental issues.
> > https://public-inbox.org/git/ab3222ab-9121-9534-1472-
> fac790bf08a4@gmai
> > l.com/
> > discusses this further.
>
> Have re-read. That was a different pair of p
Jonathan Nieder :
> Honestly, I do think you have missed some fundamental issues.
> https://public-inbox.org/git/ab3222ab-9121-9534-1472-fac790bf0...@gmail.com/
> discusses this further.
Have re-read. That was a different pair of proposals.
I have abandoned the idea of forcing timestamp uniquene
Eric S. Raymond wrote:
> Jakub Narebski :
>> Currently Git makes use of the fact that SHA-1 and SHA-256 identifiers
>> are of different lengths to distinguish them (see section "Meaning of
>> signatures") in Documentation/technical/hash-function-transition.txt
>
> That's the obvious hack. As a fu
Jonathan Nieder :
> In other words, usually the benefit of supporting multiple hash
> functions as a reader is that you want the strength of the strongest
> of those hash functions and you need a migration path to get there.
> If you don't have a way to eventually drop support for the weaker
> hash
Jakub Narebski :
> You want both more (stable IDs for all commits, not only those signed)
> and less (you don't need verification down the tree using IDs used for
> commit ID).
That's right. My assumption is that future VCSes will do their own
hash chaining in ways we don't really want to try to
Hi,
Jakub Narebski wrote:
> I think Documentation/technical/hash-function-transition.txt misses
> considerations for fast-import format (it talks about problem with
> submodules, shallow clones, and currently not solved problem of
> translating notes; it does not talk about git-replace, either).
e...@thyrsus.com (Eric S. Raymond) writes:
> I have been thinking hard about the problems raised during my
> request for unique timestamps. I think I've found a better way
> to bust the box I was trying to break out of. I am therefore
> withdrawing that proposal and replacing it with this one.
>
Jonathan Nieder :
> > I think it's a weakness, though, that most of it is written as though it
> > assumes only one hash transition will be necessary. (This is me thinking
> > on long timescales again.)
>
> Hm, can you point to what part of the doc suggested that? Best to make
> the text clearer
Hi,
Eric S. Raymond wrote:
> Jonathan Nieder :
>> Eric S. Raymond wrote:
>>> One reason I am sure of this is the SHA-1 to whatever transition.
>>> We can't count on the successor hash to survive attack forever.
[...]
>> Have you read through Documentation/technical/hash-function-transition? It
>
Jonathan Nieder :
> Hi!
>
> Eric S. Raymond wrote:
>
> > One reason I am sure of this is the SHA-1 to whatever transition.
> > We can't count on the successor hash to survive attack forever.
> > Accordingly, git's design needs to be stable against the possibility
> > of having to accommodate mult
Hi!
Eric S. Raymond wrote:
> One reason I am sure of this is the SHA-1 to whatever transition.
> We can't count on the successor hash to survive attack forever.
> Accordingly, git's design needs to be stable against the possibility
> of having to accommodate multiple future hash algorithms in the
I have been thinking hard about the problems raised during my
request for unique timestamps. I think I've found a better way
to bust the box I was trying to break out of. I am therefore
withdrawing that proposal and replacing it with this one.
It's time to separate commit identification from Mer
13 matches
Mail list logo
