Discovery and issue management is important and is not part of git.
Discovery is not there though.
It’s a protocol. You can use it against any target you like.
Though git is also not really what people would usually mean by decentralized (as it doesn't, by itself, try to connect to a pool of servers, DHT network, or something like that), it's definitely closer to it than http.
I'm also not sure "for real?" helps the conversation.
> having at least some of the processing done by the individual workstations and having information shared by and often stored at the workstations
Decentralized:
> the dispersion or distribution of functions and powers
(Both from Merriam Webster)
BitTorrent definitely fits the distributed definition (as you said), but whether HTTP is decentralized depends on how you view it. Yes, there can be more than one HTTP server, but again, there is more than one USB cable and I wouldn't call that decentralized. HTTP doesn't distribute the functions and powers between the client and the server (the two parties in any HTTP request): the client can hardly serve the response and the server can hardly issue a request. But it does distribute functions and powers between multiple servers because there isn't one global HTTP server or party that serves the Internet (now that would be a scary thought--looking at you, CloudFlare).
So it depends a bit on the explanation of that definition.
I think what I said before might be right: it's "stretching" the definition (interpreting it in a way that includes this). I can certainly see where you're coming from (anyone can host their own HTTP server just like anyone can host their own email or git server or bittorrent node) but it's not really how the word is usually used. But perhaps we use it wrong, because it does seem like a useful distinction to make (a centralized (proprietary) game server vs. a decentralized protocol like HTTP vs. a distributed protocol like BitTorrent).
You do, in fact, have a client capable of working without a central server. It's tedious but sending patches over email is definitely one way to make it work without relying on a single system. You can also have and push to or fetch from multiple servers with your client, which can be other developer's own servers, or a server reachable over Tor as a hidden service, etc. It's very flexible if you want to go that path.
Git was designed to facilitate a network of repos. For better or worse, most use cases naturally gravitate towards a single clone as the "canonical version", and unfortunately we've all got too comfortable in having that version be owned by a third party service provider.
No you don't because its missing the issue tracker which is one of the most important bits of data.