Using Git to share efficiently libraries between projects

You can go directly to the last paragraph of this post to read about my concern.


I was trying Git submodules then found the above post on Bitbucket, and it fits better my use case. The issue I had with git submodules is that my co-worker could not just pull a parent repository and just work on it without pulling explicitly the submodules also. With subtrees this complexity is gone. I can edit a shared library in any of the projects that are using it and push the commit to its remote repository. Then later in any other project that is using it I can make a pull request to have the library up-to-date. And my co-worker absolutely does not need to be aware of it for it to work.

But now I’m facing a situation that is a bit confusing, at least for me. I have a private repository for a library auth that is basically a set of helpers for authentication. I use it as a git subtree in multiple Elixir /Phoenix projects. So in my last project I have to deal multi-lingual content and I prefer that each application in the project handle the internationalization through its own Gettext backend. Then in my auth library I generate content in multiple languages for that project. But other projects that use this same library don’t necessary need those translations files.

So I’m wondering how to use .gitgnore files so that a parent git repository keep trace of a folder it generated inside a subtree repository, while the subtree repository should ignore that folder when pushing to its own remote repository. The folder in my case is the one that contains the Gettext translations. I can ignore the folder in the subtree repository, but is not it meaning that the main project repository will also follow that rule?

2 Likes

I’d rather not discuss Git submodules because I heard from several people that they are bad news. I haven’t used them so can’t comment.

In your case you might want to do two things:

  1. Self-host a private Hex repository.
  2. Put your common code there as a library.

I gathered from your post that you don’t want that common code to be public so this likely the solution you are looking for?

3 Likes

Thank you for your reply @dimitarvp.

Yes that is right . And that is why git subtrees are likely better.

My first tought was putting them in a private Hex repository. At that time, they were still free I think. Private, not because these libraries contain sensitive information. More because I didn’t feel enough confident with my skills in elixir (no test and probably buggy code), I did not see too much use for other people.

I will maybe give it another try now and make some codes public in Hex packages.
After all, they may inpire other people to contribute or pointing me to the case there are already other libraries for a specific feature. :slight_smile:

2 Likes

You are very wrongfully assuming that anyone even cares. :laughing:

Just do it, man. Make a common library, put it up publicly with a short note on what it does and how – don’t need to be detailed. Nobody guarantees any future readers they’ll find anything of use. The amount of abandoned projects out there is gigantic. Just don’t think about it and do it how it’s easiest on you. If that means a public repo, so be it.

3 Likes

Well I will not recommend to pollute the hex.pm with packages we don’t want to maintain… For this situations I just retrieve the package in mix.exs from Gitlab or Github. I am doing this with several packages I developed, but don’t want to maintain.

3 Likes

That’s exactly my point – now that I reread my post, it’s not clear, sorry. I meant put it on GitHub and don’t put on hex.pm indeed.

4 Likes

Git submodules are entirely fine, the issue with them is that people have a tendency to forget to pull them, easily fixed by a build system that does it for you.

Git subtree is useful if you want to vendor in something (or peel it out), but it infects history in some annoying ways at times, plus you then have a fork that you can’t as easily reuse.

3 Likes