Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

git

github

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.

like image 462
argoneus Avatar asked Sep 16 '10 00:09

argoneus


People also ask

What is the best practice for dealing with passwords in git repositories?

Encrypt the sensitive data (purpose of this reply) If you want to store your config files containing sensitive information (like passwords) in a public location then it needs to be encrypted. The files could be decrypted when recovered from the repository, or even used straight from their encrypted form.

Which of the below language is supported by git?

Core languages supported by GitHub features Core languages for GitHub features include C, C++, C#, Go, Java, JavaScript, PHP, Python, Ruby, Scala, and TypeScript.

What programming language does git use?

Git was designed as a set of programs written in C and several shell scripts that provide wrappers around those programs. Although most of those scripts have since been rewritten in C for speed and portability, the design remains, and it is easy to chain the components together.


1 Answers

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.
    • git describe is a nice feature to identify a version based on the latest annotated tag. With just one implementation in the repository, git describe usage is simple. But if different implementations with separate version numbers are in the one repository, then git describe usage becomes more complicated, needing use of the --match option to limit to tags with a given prefix. e.g. git describe --match "python*"
  • 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.
like image 131
Craig McQueen Avatar answered Sep 20 '22 19:09

Craig McQueen