Yes of course I known git submodule. It works fine. It's just a reference to another git repository with the commits SHA as reference for the checkout (or the "revision" if you prefer the CVS terminology).
Maybe they are usefull for something, not sure.
I tried to have projects and their libraries in different Git repos and configure them as submodules. The idea was that checking out an old project revision would bring out the required library revisions, too.
Submodules were not suitable for that. They are only suitable for related projects but I don't see the real benefit.
What you miss in my POV is that a git repository contains all the project history.
So when a project needs, for example, a dependency to be at v0.8.1 while the master is at v0.9.2, the package manager could simply call git checkkout v0.8.1...
But your answer doesn't surprise me at all.
Now I understood that every package would have its own repository. Ok, then "git clone" and "git pull" would work.
Revision control tools make sense for textual data. It does not make sense to store the compressed meta-package there. The package source files must be stored instead. Then after a checkout there must be an automated process to build and compress a meta-package. Tell me, what is the benefit compared to just compressing the packages once and leaving them in a file system?
Things would be different if the data was constantly changing and we had thousands of revisions. That is the case when revisioning a software development process. Git is very good in that. That's why I use it myself.
The online package server is different. There are 2 or 3 versions of each package that must be supported. They don't change once they are released. Clearly a revision control tool is not needed for that.
It is importand to always use the right tool for a given task.
Git can be used for developing the package sources where ever that happens.
Such a repository indeed contains
all the history but it is a whole different process.
Actually the idea is influenced by another packet manager & build tool. It uses git to download and set a dependency to the right revision. I don't like it much but it works fine, using git is a big win for it.
Which one?
I have an open mind and want to learn about this topic.
So far I have not seen any benefit that Git would bring to the online package system. On the other hand it brings many problems and complications. For example Lazarus would then depend on Git libraries also on Windows. Git on Windows requires MinGW Unix emulation.
I would say it is a no-go.
Recent
