Proposal and Validation of Git Compile

Proposal and Validation of Git Compile

[Bhargav Vishnu]

[-- Attachment #1.1: Type: text/plain, Size: 1733 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 2091 bytes --]

[-- Attachment #2: working.jpeg --]
[-- Type: image/jpeg, Size: 800063 bytes --]

Re: Proposal and Validation of Git Compile

[Reto]

On Tue, Mar 12, 2024 at 11:24:17PM -0400, Bhargav Vishnu wrote:
> - 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?

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.

Re: Proposal and Validation of Git Compile

[Konstantin Khomoutov]

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

> I'm writing to propose and get a validation of one of the ideas I had for
> git tool.
[...]
> Eg: Code on a gist is copied into every repository, why not create and use
> the gist itself as it also has versioning?
[...]

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