Love the idea. Clearly you've put a lot of thought into the current revision of the naming spec. Regardless of the outcome of my new, pie in the sky discussion I think that your spec should continue to move forward because it is low hanging fruit.
Reading your spec spawned an idea in my head that I've been considering for a while. What is the best way to publish and obtain metadata about a repository without needing to clone the entire repo? This need not be semantic but rather needs to be quickly walkable by a machine and be able to be checked in post-push hooks on the server.
This is a difficult problem since there are so many ways that git is used. Some organizations split out their code into many repos, others use a single monolith repo with submodules or subfolders to make smoke testing & dependency management simpler. In the end, I think this question of metadata is orthogonal to the semantic naming spec since it speaks to much more than just how do we name repos. It speaks to how do we structure our organization, our dev channels, etc.
There are additional concerns when you consider that target names and platforms change over time. Do you deprecate entire repos or rename them when changes occur?
Initially, I considered whether this could be solved using Git Notes. The problems and pitfalls seem to be vast. The feature's author seemed to indicate that it is experimental at best. It also seems that notes apply to a specific object and not to a repository as a whole.
For this reason it might be more beneficial to use a repo specific branch naming convention like github pages does. So you'd git clone -b semgit --single-branch git://sub.domain.com/repo.git then your tools would look for a file called semgit which follows the existing .gitconfig format. If you really wanted to make it flexible you could allow for adapters that would allow for metadata in yaml, json, xml or other parseable formats.
This would give metadata publishers the freedom to change metadata independent of repo contents and allow metadata consumers the ability to grab just metadata and not the entire repo.
Take-a-ways / tldr:
metadata values and field requirements change over time
multiple targets exist, targets change over time
repo renames suck in large teams
enable repo metadata tools
Again, this might be best as a completely separate spec / repo but since they both cover repo metadata I figured I'd begin what I see as a requirements gathering discussion.
Hello hello,
Love the idea. Clearly you've put a lot of thought into the current revision of the naming spec. Regardless of the outcome of my new, pie in the sky discussion I think that your spec should continue to move forward because it is low hanging fruit.
Reading your spec spawned an idea in my head that I've been considering for a while. What is the best way to publish and obtain metadata about a repository without needing to clone the entire repo? This need not be semantic but rather needs to be quickly walkable by a machine and be able to be checked in post-push hooks on the server.
This is a difficult problem since there are so many ways that git is used. Some organizations split out their code into many repos, others use a single monolith repo with submodules or subfolders to make smoke testing & dependency management simpler. In the end, I think this question of metadata is orthogonal to the semantic naming spec since it speaks to much more than just how do we name repos. It speaks to how do we structure our organization, our dev channels, etc.
There are additional concerns when you consider that target names and platforms change over time. Do you deprecate entire repos or rename them when changes occur?
Initially, I considered whether this could be solved using Git Notes. The problems and pitfalls seem to be vast. The feature's author seemed to indicate that it is experimental at best. It also seems that notes apply to a specific object and not to a repository as a whole.
For this reason it might be more beneficial to use a repo specific branch naming convention like github pages does. So you'd
git clone -b semgit --single-branch git://sub.domain.com/repo.gitthen your tools would look for a file called semgit which follows the existing .gitconfig format. If you really wanted to make it flexible you could allow for adapters that would allow for metadata in yaml, json, xml or other parseable formats.This would give metadata publishers the freedom to change metadata independent of repo contents and allow metadata consumers the ability to grab just metadata and not the entire repo.
Take-a-ways / tldr:
Again, this might be best as a completely separate spec / repo but since they both cover repo metadata I figured I'd begin what I see as a requirements gathering discussion.