Talking Git On IBM i With A Bunch Of IBM i Gits

July 13, 2026 Timothy Prickett Morgan

If there is someone on planet Earth who is most definitely not a git, it is Linux operating system kernel and Git version control system creator Linus Torvalds. The term git was absolutely meant to be pejorative, but it has softened over the years in part because Torvalds chose the name for his version control system precisely to mock himself. The meaning of git is shifting from incompetent senile fool toward curmudgeon and is heading toward old fart.

Torvalds manages one of the largest software projects in the world, and in the early 2000s chose BitKeeper, a proprietary source control management system, to manage patches to the Linux kernel. The open source Subversion and CVS didn’t impress Torvalds, and when the Linux project had some difficulties relating to BitKeeper, in a huff over a 10-day period, he created the Git repository and source control manager explicitly to manage the Linux kernel’s massive development and patching effort. Within a few weeks, Git was running in production at scale. That’s pretty impressive, if you think about.

Since then, Git in various guises has become the de facto version control system used for open source and closed source software development projects – something Torvalds was not thinking about when he created Git.

ARCAD Software, the venerable maker of software change management tools for the OS/400 and IBM i platform for the past four decades, saw the potential for Git early on and embraced it as well as other open source tools to transform its tools into a full DevOps suite. There is a lot of talk about Git and IBM i these days, with a wide variety of opinions about how important Git is and the best way to integrate it with the IBM i platform. I sat down with ARCAD’s founder and chief executive officer, Philippe Magne, as well as Jeff Tickner, chief technology officer for North America, and Alexandre Codinach, vice president of sales and operations for the Americas region, to have a chat about all of this Git chatter.

Timothy Prickett Morgan: Jeff, can you set the scene? What has ARCAD’s experience been with Git integration over the years?

Jeff Tickner: ARCAD has been integrated with Git for ten years, and in that span of time we have had to rewrite the process multiple times. As we rolled it out to our customers, we learned from that and optimized and improved – and we never stop improving. One example: We’ve had a rebase function available for a few years, and we just rewrote it completely.

TPM: What is a rebase function, exactly?

Jeff Tickner: Rebase is a way to reconcile your changes between branches. It’s a very powerful Git feature — so powerful, in fact, that some people don’t use it at all because it can have a significant impact. Some folks say never use rebase because it’s just too dangerous. We offered it as a function in all of our Git methodologies, and when customers actually started using it, they wanted more feedback. So we went back to the drawing board. We essentially set it up as a two-cycle process: test the rebase, see the results, and if you like the results, then execute it. The point is that whatever methodology you’re using, you can leverage as much of the Git functionality as you want — or as little as you want. And we’ve learned two things when we provide access to Git functionality: first, you have to optimize it, because for customers with a large source base some Git operations can be very slow; and second, you have to provide a high level of feedback.

TPM: When you are running Git in this context, where is it actually running? Is it on an external server, on a Linux partition, or is there a copy on the IBM i platform itself?

Jeff Tickner: It is in multiple places. We always have a common Git server – GitHub, GitLab, something like that – that is not on the IBM i. All of the developers, whatever platform they’re working on, interact with that common copy of Git. And then we have a copy of Git on the IBM i that we use as a kind of staging area for the developer to interact with. We use that for builds, and when the customer is working directly in a library, that local copy of Git is really used to provide a testing environment – a place where they can test things like that rebase before pushing anything up to the shared server. Once you push to the shared server, you’re potentially impacting everybody else. So we give the developer a way to test first: Do I have a conflict on this rebase, do I actually have changes that need to go up, or am I already at the same level as the server? The reason we do it that way is optimization. The less we have to talk to the server during a technical operation, the better.

TPM: When other developers are using Git on Windows or Linux, they just interact with GitHub or GitLab natively and don’t see the IBM i on the other side at all. They just see code coming in, written in COBOL or RPG.

Jeff Tickner: Right. And what we’ve found across our customer base is that the common ground is SQL. I have customers where off-platform developers are now contributing to the DB2 structure through SQL. SQL is a common language, though it’s not 100 percent portable – IBM i has been catching up to syntax that’s perfectly valid on other platforms but not yet valid in DB2. Git is a real help there, because when those contributors make changes through our repository, ARCAD steps in and says: you used our repository to make that change, so we’re going to build it and verify the syntax before we apply it.

TPM: So that sandbox works in both directions.

Jeff Tickner: Exactly.

TPM: Can you compare this to what else you see in the market? What range of customer requirements are you dealing with?

Jeff Tickner: No two customers have the exact same workflow or tool set. When a customer comes to us and says they want to use Git, the first question we ask is: why? Some see Git as a source control mechanism and want to dig into the full technical utility. Others need to use Git as a corporate mandate – their source has to be in Git to expose it to developers on other platforms, or it’s simply a company standard – but the IBM i developers themselves don’t necessarily want the complexity of Git. That’s where we started offering different methodologies. We can get to a point where the developer can’t even tell they’re using Git – we’ve abstracted it so completely that it looks like you’re not using Git at all, but you actually are doing a two-way interaction with it.

Alexandre Codinach: The key question is always, what is the objective? When someone says they want to move to Git, that doesn’t mean anything on its own. Do you want to optimize parallel development? Do you have an audit requirement? Is it a company mandate to move all code to Git? And then: what is your architecture? Are you going on-premise or cloud? There are security constraints as well. Git is distributed by design – in the Linux world, if you have an application with ten thousand components, the first thing a developer does is download the entire copy of the source to their laptop. That’s how Git works. And we have customers who wanted to move to Git but were not comfortable with their developers having the full business application on a personal laptop.

TPM: I would not be happy about that either. That sounds like a security risk to me.

Alexandre Codinach: Exactly. When an IT manager at a bank understands that their developers are going to carry the entire critical application home on a laptop, they don’t want that. So we also provide a way to use Git and expose all of its technical features – from a simple pull request to the complex rebase – without having all of the application source on the developer’s laptop.

TPM: How do customers tend to handle Git hosting? Do they want to keep it on-premise, or are they comfortable with GitHub or GitLab in the cloud?

Alexandre Codinach: It depends on the customer. Bitbucket, for example, is cloud-only now — they no longer maintain the on-premise version. The broader trend seems to be toward the cloud, but we have all kinds of customers. Some want to keep Git on-premise and they’re not moving. The good news is that moving from one to the other is not a big deal. And interestingly, customers are generally more comfortable putting source code in the cloud than they are putting it on a developer’s laptop. Those are different levels of risk.

TPM: Philippe, can you talk about the architectural of the ARCAD stack and how it integrates with Git? And what special sauce are you bringing to that Git integration?

Philippe Magne: The main reason people are embracing Git is parallelism. The traditional change management tools from 20 or 40 years ago are based on waterfall methodology – one component, one time, in one environment. Git is the exact opposite of that. And the reason ARCAD has mapped onto Git so well, and why we were so fast to integrate with IBM’s RTC product years ago, is that our architecture, since inception, has been built around the notion of a version library: for one project, you have one library where you store all the different changes. That is what allows you to have multiple releases in flight at the same time – which is exactly how Git functions.

Jeff Tickner: We have a library for every branch, and that’s a significant distinction. Every branch in Git has a corresponding library in ARCAD. We maintain the same isolation that Git provides in branching.

Alexandre Codinach: He is too modest, but Philippe designed that architecture thirty years ago without knowing Git would exist. But the foundation of ARCAD was already Git-compliant. We started calling our process “integration” thirty years ago – continuous integration, which is now considered a modern DevOps concept, but ARCAD was doing it from the beginning under that same name.

TPM: Do you support a legacy repository alongside Git? Are customers who are perfectly happy with the existing ARCAD tools being asked to move to Git, or is this something they choose to do on their own timeline?

Jeff Tickner: We actually have a highly automated transition to Git. We have had many customers migrate from our more traditional development processes, and because we’ve done this at scale, we’ve had to automate it. I can now run a script that goes through all the in-process projects, updates them, and pushes the changes to a Git branch — using the developer’s name to track everything they made outside of Git. What used to take me a full weekend of manual work now runs for a couple of hours unattended.

Alexandre Codinach: The other key point is supporting the transition to Git progressively. A young developer who is 22 or 25 years old grew up with Git – it’s natural to them. But you may have people in the same team who are over sixty-five and working in a traditional way, and you cannot afford to lose them because they carry deep knowledge of the application. So we provide a way to move to Git that supports that kind of progressive transition. You can continue to work in the traditional way while others are fully in Git, and the system bridges them.

TPM: Is the overall recommendation, then, for shops that aren’t yet using ARCAD: Adopt the ARCAD stack, move toward Git at whatever pace your team can handle, keep your experienced programmers productive, and position yourselves to bring on younger developers who are already working in Git-based environments?

Jeff Tickner: That’s the goal, yes.

Alexandre Codinach: That’s the ultimate objective. It does no good to target the most advanced Git architecture if your team can’t follow along and can’t be onboarded to it. We evaluate the maturity of the team at the beginning, and we provide an integration approach that’s actually achievable for them – and then they can grow from there.

Jeff Tickner: There is one more point worth making: we assumed when we started this work that companies using Git already had it everywhere, and IBM i was the last group to come on. What we actually found was sometimes the IBM i is the first. We’ve had customers where we rolled Git out at the entire company starting with the IBM i, and the other developers came on afterward. That surprised us. It’s not the most common scenario, but it’s out there — and it reflects the nature of the IBM i customer base.

TPM: Philippe, anything else before we wrap up?

Philippe Magne: Yes. We need to talk about AI adoption. The attraction around Git is also being driven by the fact that AI tools are much more comfortable operating from within a Git repository. IBM made an early misstep with Bob – the initial design required downloading all the sources outside of the IBM i, which reflected a limited understanding of the IBM i environment. They corrected that with later releases. But the underlying point is that the number of people wanting to embrace Git is increasingly tied to AI. That’s now a major driver.

Jeff Tickner: And further on that point: When you have AI updating your code, a Git branch gives you the natural place to do that with proper isolation. If IBM allows an AI tool to go into a programmer’s library and start updating source, does the developer really want that AI going through everything they’re working on? Or do they want a sandbox? Do they want isolation and a human review before any of those changes go further? That’s exactly what Git provides: you start in a branch, and then you get a pull request and a peer review before anything moves into a QA branch or production. Giving an AI a full programmer library and saying “go to town” is a very different thing from giving it a scoped, isolated project library in ARCAD and letting it work within those boundaries.

TPM: Understood. That’s an important distinction – and not one I would have arrived at without this conversation.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search