Our production release process is a nightmare because it revolves around Clearcase. We have a change management group who executes all releases and who will only allow code into production that was taken from it.

No, your process is a "nightmare" because of your change management group and your release procedures. Go ahead and replace Clearcase for SVN or git or Fossil. You'll have the exact same problems. (I think they're doing it right TBH, strong release controls are essential).

This is what you need ot focus on, not the geeky credentials of git (which are irrelevant to all but the devs), you need to focus on the business case for changing the process to mae it less onerous. Chances are you can do that using Clearcase, but it gives you an opportunity to sneak the idea of using git in anyway.

If you don't look at the "bigger picture" here, the best case you'll get it to use git with the same restrictions the release group require. IF you do consider the wider aspects of what change control is for, then you'll appreciate the restrictions you'll have to implement to make git useful in the kind of strongly-controlled release process your org needs.

Our production release process is a nightmare because it revolves around Clearcase. We have a change management group who executes all releases and who will only allow code into production that was taken from it.

No, your process is a "nightmare" because of your change management group and your release procedures. Go ahead and replace Clearcase for SVN or git or Fossil. You'll have the exact same problems. (I think they're doing it right TBH, strong release controls are essential).

This is what you need to focus on, not the geeky credentials of git (which are irrelevant to all but the devs), you need to focus on the business case for changing the process to mae it less onerous. Chances are you can do that using Clearcase, but it gives you an opportunity to sneak the idea of using git in anyway.

If you don't look at the "bigger picture" here, the best case you'll get it to use git with the same restrictions the release group require. IF you do consider the wider aspects of what change control is for, then you'll appreciate the restrictions you'll have to implement to make git useful in the kind of strongly-controlled release process your org needs.

Some ideas for you: Get them to see the productivity issues with the current system from a developer point of view. Do this as part 1 of 2. Part 2, go and work with them on a release so you can see the control issues that you developers need to understand. Treat it as a learning exercise for both sides to view the other side's view, and then you should be better able to come up with a solution that still solves the major requirements either side has. Note that releases are more important than dev, so you should be the one prepared to give ground more than you expect them to.

Once you have the knowledge of what's required for releases, you should agree to write up a process document detailed (with steps-to-follow kind of detail) that you can show them giving them what they need. How you can massage this so the dev side is better for you is up to you. I imagine they don't really care how dev does dev, as long as the source is properly managed and releases correctly organised - that means you'll have to show how code changes can be tied to change tickets, how to take code that made a release to patch, build and re-release it.