Proposal and Validation of Git Compile

Hello,

I'm writing to propose and get a validation of one of the ideas I had for git tool. Background: We are currently able to clone the complete repository and access the code. Why don't we allow only part of the code maybe a few lines to be imported into the repository?

Issues:
- Developers have duplicate code within which could be a utility file and
some repositories have whole sets of codes like the Algorithms repository.
We would only require a particular algorithm from that repository, in those
cases, there isn't an easy way to import that snippet.
- A large amount of similar duplicate codes are written by authors in
different personal projects like utilities. These must be made reusable.
Eg: Code on a gist is copied into every repository, why not create and use
the gist itself as it also has versioning?

Idea:
- Specify a syntax which specifies how to import the gist or snippet
- When creating the file use the syntax to import the snippet
- Users need to compile the new file to resolve the snippet but the
decompiled version with the syntax is retained in the cache
- When the user pushes the file use the decompiled version but not the
compiled version so that the git hosted on the server can make references
between repositories and gists
- When another user pulls the decompiled file, the file is compiled as part
of git pull and resolved in the remote reference with the snippet so the
user can run the code.

Issues: Syntax might not be recognized by editors Trust external author's code in production

I have attached the workflow below

I would like to know if there is a better way to solve this issue and avoid code duplication as I have limited knowledge of git.

Thank You

With Regards Bhargav

On Tue, Mar 12, 2024 at 11:24:17PM -0400, Bhargav Vishnu wrote:

You are re-inventing the normal dependency packaging of the languages, poorly. We already have language specific ways (npm, pip, cargo, go get...) for almost all ecosystems. They have version controlled and checksumed dependency resolution and are actually aware what's needed (binary vs source distribution, additional deps etc).

I don't see why you'd want your version control system to do it, rather than using what already exists.

"Code on a gist is copied into every repository" is what we call a library, so package it up and pull it down with your favorite dependency management tool during the project build.

On Tue, Mar 12, 2024 at 11:24:17PM -0400, Bhargav Vishnu wrote:

[...]

[...]

In addition to what Reto said in their respective answer, you seem to confuse Git (a version control tool) and Github - a turn-key Git hosting solution. The thing is, the concept of "gists" does not exist in Git, and also it does not have any real concept of a repository fork, a pull request, issue tracking and so on. That is, to build what you propose on your workflow picture, you'd need to implement it in Github, not Git.

That said, I support what Reto said: Gists are merely pastebins [1] of the 21th century, and I think you perceive them as version-controlled code because you supposedly are a relatively young person ;-) For an old fart like me, Gists are just a sort of convenient way to share snippets of code with someone else (say, when you're chatting on StackOverflow or elsewhere and would like to show to your peer a bit more than a one-liner).

And if we think about making reusable pieces of code, this is ineed a solved problem: libraries, packages and package repositories. Not that I do not find your idea having a particular appeal - it does, - just it's not in the domain of Git itself. A packaging system could possibly somehow intergate with Gists (but note that that could only really sensibly work for interpreted languages such as JS, which you seem to think of anyway), but that's a task for that package system, not Git. For instance, Go's package management system allows storage of the packages (in the form of the source code) using multiple VC systems - namely, Git, Mercurial, Fossil and Subversion, and it's semi-transparent to the users. Note that implementing this package system did not require any support from the mentioned VC systems. Quite possibly, say, NPM, could be made to work with Gists in the way you envision, but it's to be discussed with NPM folks, not Git folks.

 1. https://en.wikipedia.org/wiki/Pastebin