Sounds like you're evaluating software configuration management for Smalltalk from before that was hardly a thing for any development platform?
Decades ago, Smalltalk implementations would let you dump some part of a system (say, the part that held your application) to a human-readable ASCII file (which is pretty Git-able), and also load that. If you were using it today, while we're using Git, I can't think of a reason a Smalltalk system couldn't have more tight integration with Git.
Regarding Lisps, I'm not sure which school of thought you're coming from, but there are multiple. To someone without firsthand experience, the things you might've heard someone say, like "Foo is great because code and date are the same darn thing", or "Foo is great because it's dynamic up the wazoo", not only aren't necessarily the strengths that others would claim, or they might not mean the same thing.
For example, imagine some kinds of syntactic extension in Lisps, in which some region of syntax isn't a function call. The region is clearly delimited, and it has an identifier right there that can be looked up to tell you the behavior. Someone without experience with that, but who has used an unfortunate kind of "DSL" in some other language, or, worse, has experienced surprise "operator" overloading in a different language, or who's seen unfortunate choices of when to introduce languages and when not, might think this Lisps thing is more of the same thing, when it's not.
Pharo, at least, has very tight integration with git via Iceberg. Other variants have had (not from personal experience, only reading what others wrote) very good or at least decent (that is, no worse than the rest of industry) version control at least back to the 90s.
I worked on a team of about 20-25 devs. We used the Digitalk toolset, using Team/V for source control. You opened a repository/package browser instead of a class browser. There was versioning at all levels and good package management.
Envy/Developer was in heavy use where I worked, and it was pretty great but still nothing like the packagement management tools we now have.
I'd say the change log in something like VisualWorks was definitely not git-able in any way that would facilitate merging of several developers code. In fact it was extremely difficult to keep images in sync without something like Envy/Developer.
When I used ParcPlace Objectworks Smalltalk 4.1. and then VisualWorks Smalltalk in the early '90s, you'd use a menu item to write a human-readable ASCII serialization of some part of the system (not changelog) to the host filesystem. And it'd be diffable and mergeable and loadable.
Doing Git with just that seems only a little different than what we'd do with a collection of source files today in some other language, including branches and merges.
At the same time, one commercial site I worked at was doing its SCM for C code using kludge scripts over SCCS to an NFS volume. The next was putting C and C++ into Apollo DSEE and making SPARCstations jump through hoops to use that (because ancient DSEE on some Apollo DN10ks for SCM and CI/CD was better than the state of the art almost everyone else was using) and my advanced R&D group had just gotten DSEE-descendant Atria ClearCase for greenfield work in C++ from our Sun and HP workstations. The next site was using some dumpster fire of `.BAT` scripts over Perforce(?) for Windows NT-dominated C++ development.
I'd say VisualWorks Smalltalk's wasn't the problem for team development at the time. The state of practice of everything else was more the problem.
Evidently you have some experience with Smalltalk, but what makes you say that about Lisp? Also which Lisp exactly do you have in mind? To me the Lisp family of languages is more like Classical music: it doesn’t satisfy some modern sensibilities, but it has a timeless elegance and will be around long after the latest fad is gone.
It's a personal opinion more than anything. I see Clojure getting attention but it isn't going to replace Node.js or .NET any time soon.
The major difference being the ecosystem built around something like C# is miles ahead of anything available for even Clojure. Some people might think that's an advantage, but for people like me whose job is to be pragmatic and "git er dun" it's a major impediment.
Hence, lisp has become a kind of toy from a golden age. I find myself reaching for C# or Python for experiments. I have dabbled in lisp occasionally over the years but never found Clojure very compelling.
Clojure has access to the same ecosystem as C# since it runs on the CLR and can use .Net libraries and frameworks.
It can also have access to the whole Java ecosystem or JavaScript ecosystem. Funny enough, it can also use most Python libraries. And if you're willing to go less official, it also can be used to leverage Erlang's ecosystem and recently Dart and Flutter.
Unless you meant something different than being able to leverage libraries, frameworks and some of the tooling?
You come across as someone with minimal -if any- experience with Lisp, to be making some of the generalizations and grandiose proclamations that you do. Also, lots of people don't consider Clojure a Lisp.
I too have a significant physical Lisp library, including TAotMOP. I’m also a bit of a curmudgeon and don’t love some of Clojure’s syntactic novelties. But even so I agree that Clojure is a Lisp. Lacking proper tail recursion really isn’t disqualifying. The workflow with CIDER is quite familiar for anyone with Common Lisp experience. I understand there are solid dev plugins for other editors too.
We had a previous discussion, and my impression was tools don't matter when — "Yeah, there were a lot of side channels for sharing code that made merging things more difficult than they could have been. Poor discipline when devs were in a mad rush."
Decades ago, Smalltalk implementations would let you dump some part of a system (say, the part that held your application) to a human-readable ASCII file (which is pretty Git-able), and also load that. If you were using it today, while we're using Git, I can't think of a reason a Smalltalk system couldn't have more tight integration with Git.
Regarding Lisps, I'm not sure which school of thought you're coming from, but there are multiple. To someone without firsthand experience, the things you might've heard someone say, like "Foo is great because code and date are the same darn thing", or "Foo is great because it's dynamic up the wazoo", not only aren't necessarily the strengths that others would claim, or they might not mean the same thing.
For example, imagine some kinds of syntactic extension in Lisps, in which some region of syntax isn't a function call. The region is clearly delimited, and it has an identifier right there that can be looked up to tell you the behavior. Someone without experience with that, but who has used an unfortunate kind of "DSL" in some other language, or, worse, has experienced surprise "operator" overloading in a different language, or who's seen unfortunate choices of when to introduce languages and when not, might think this Lisps thing is more of the same thing, when it's not.