4 ms·

Is this a git issue or a github issue? I know git is being (mis)used, but the issues seem to be with github. Maybe a better title for those of us with no intere

Is this a git issue or a github issue? I know git is being (mis)used, but the issues seem to be with github. Maybe a better title for those of us with no interest in github would be "Github hides git files in plain sight" ?

nebulous1 3y ago
I think there is no issue. But, yes, it seems like if there is one then it's with the github UI.
everybodyknows 3y ago
[deleted]
- semiquaver 3y ago
  The `junio-gpg-pub` key is a blob in the git repo for git, ie ssh://git.kernel.org/pub/scm/git/git.git You won’t see it in any repo, just that one. This is not an easter egg in the git binary, just a quirky way to transmit a signing pubkey via a non-tree git sidechannel within the git source repo.
WorldMaker 3y ago
It's not an issue with either, they are both working "as intended". Both examples are storing data in git's object database. Git and GitHub clone the object databases as fully as they can. To keep the objects "live" in the database both examples use non-standard git refs. Git's raw object DB format was designed to be extensible so it supports non-standard refs that don't reflect (aren't reflected in) high-level git concepts (such as branches and commits). Because these examples use such non-standard refs there's not a standard UI for them in GitHub. It's probably not a great idea to use or rely on non-standard refs in general because it may conflict with other tools or future git capabilities, even if there were a "standard UI for unknown refs".
theamk 3y ago
that functionality is pretty useful -- we use hidden refs (but more garden variety, pointing to commits) for all sorts of things, such as source revision for every CI run and past revisions of PRs. Works really great -- the UI is not cluttered with thousands of rarely-used entries, but all the data is still backed up and usable witth git tools. Now if only github actions could support this...

nebulous1 3y ago

I think there is no issue. But, yes, it seems like if there is one then it's with the github UI.

everybodyknows 3y ago

[deleted]

semiquaver 3y ago
The `junio-gpg-pub` key is a blob in the git repo for git, ie ssh://git.kernel.org/pub/scm/git/git.git You won’t see it in any repo, just that one. This is not an easter egg in the git binary, just a quirky way to transmit a signing pubkey via a non-tree git sidechannel within the git source repo.

WorldMaker 3y ago

It's not an issue with either, they are both working "as intended". Both examples are storing data in git's object database. Git and GitHub clone the object databases as fully as they can. To keep the objects "live" in the database both examples use non-standard git refs. Git's raw object DB format was designed to be extensible so it supports non-standard refs that don't reflect (aren't reflected in) high-level git concepts (such as branches and commits). Because these examples use such non-standard refs there's not a standard UI for them in GitHub. It's probably not a great idea to use or rely on non-standard refs in general because it may conflict with other tools or future git capabilities, even if there were a "standard UI for unknown refs".

theamk 3y ago

that functionality is pretty useful -- we use hidden refs (but more garden variety, pointing to commits) for all sorts of things, such as source revision for every CI run and past revisions of PRs. Works really great -- the UI is not cluttered with thousands of rarely-used entries, but all the data is still backed up and usable witth git tools. Now if only github actions could support this...