Exactly... anybody who wants to be able to say "This is a git object id for a thing" rather than "this is a random sha1" (or perhaps someday, sha256), and more importantly... if presented with say... the same contents outside of a git repo repeat the computation of the git object id and see that it's referring to the contents they have in their hands. That had been my original thought around including the 'object type' (gitoid:blob:sha1:261eeb9e9f8b2b4b0d119366dda99c6fd7d35c64) because if presented with an array of bytes outside of a git repo, if I want to know whether or not it matches the git oid, I need to know what git object type to put in the git header prepended to the contents. I have a tendency to generalization though, and so its'1 good to get feedback from folks closer to git as to whether that makes sense or not. As a side note: in case I'm being unclear: there is no conceivable universe in which I'm advocating for git to change anything it does around this conversation. I'm just seeking 'advice'. Among the space of valid advice being: "don't reinvent the wheel, these folks already have a perfectly serviceable wheel" Ed On Tue, Mar 1, 2022 at 12:30 PM Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Mar 01, 2022 at 11:58:01AM -0600, Ed Warnicke wrote: > > Konstantin, > > > > I suspect you read a bit more into my question than I intended :) I > > do appreciate the breadth of your thought about it though :) > > Ah. Sorry, my perception is understandably tainted in the past few days. > > > Mostly, I'm just looking for a way to express the git object id as a > > uri scheme so completely outside-of-git things can refer to it clearly > > (ie, know to prepend the object header before hashing to see if the > > contents match). > > Okay, I understand -- so for purposes like adding to sigstore or other supply > chain tracking systems? > > -K
