What's the best practice with git for multiple language implementations?

Question

So I have a few private git repositories that are different language implementations (Python, Java, etc.) of an algorithm. Each implementation is functionally identical, performing the same steps and giving the same output. Currently, these are separate repos, but I was wondering if I shouldn't unify them into one repo, with directories indicating the language, like:

  master
     - java
     - python
     - ruby

I could use a git-repo combine command to preserve the history, so that's not an issue. I was just curious as to the best practice regarding this.

Answer 1

I had this same question with Mercurial, and an algorithm (COBS) that I wanted to implement in C and Python.

Eventually I decided to split it into separate repositories (even though the Python implementation included a C extension that had similar code to the plain C implementation). My reasoning came down to:

• I wanted to have independent version numbering of the implementations, and independent releases.
• The way Python modules are typically organised (Python module packaging best-practices), it made more sense to me to keep the Python implementation separate and self-contained.
• All else being equal, I tend to favour more fine-grained modularity.

Answer 2

It's a tough call. Probably what's "best" will just boil down to personal preference and/or the specifics of the circumstances at hand.

On the one hand, each directory isn't technically "related" to any other. While they do implement the same algorithm, none depends on any of the others (so from a pure source code point of view, they are unrelated). Usually, unrelated things are best left in separate repos (for reasons identified in Craig McQueen's answer).

However, because they do implement the same algorithm, you may find that if you need to change the algorithm, you'll need to make very similar changes to all of the directories. In such a case, it might make sense to make all of the changes as a single commit. Let's say you decide the algorithm needs to support "virtual dinglehoppers". You'd add that support to each directory and make a single commit whose message is "Add support for virtual dinglehoppers". This is nice because if you later decide that adding virtual dinglehopper support was bad, you can now revert just a single commit. The alternative is to make three separate commits to three separate repositories and then revert three separate commits from three separate repositories.

Again, it's a tough call. I don't think there's a clear-cut, hard-and-fast rule to go by.