Idea how to make GIT link aware written on 27 november 2021 by Skybuck Flying/Harald Houppermans and posted on "Git for human beings" newsgroup:

Programming languages like C, Delphi, Python, Java, C#, C++ and others often have include and import and use clausules and such in their program files..

For example:
include "filea.h";
uses fileb;
import graphics;

These pieces of synthax describe how the files are linked together and how they dependent on each other.

Each compiler writer/language designer could write a small little tool/parser that GIT.exe could use to discover links/dependencies between files.

Even graphics and other file types could make use of this feature/idea.

This allows GIT to become aware of what could be considered a "dependency" map.

Such a dependency map, or "view of dependency" would allow certain desired features.

One very important one is including version numbers/information in files, which is currently completely lacking.

Problem example:
file.a includes/uses/imports/depends on file.b

There are now three scenerios:

scenerio 1: file.a is changed/updated
scenerio 2: file.b is changed/updated
scenerio 3: both are changed/updated

question/problem:
which version of file.a used which version of file.b ?

There are two ways to tackle this problem:

1. Either development environments are made aware of git and different
versions.

2. Or the version information gets exported from git and stored into the files
themselfes, either in the file system as a special field, or appended to the filename.

Examples of solution 2 are:

file.a.version.001
file.b.version.001
file.a.version.002
file.b.version.002

Now for a more complex example to illustrate better the requirements:

file.a uses file.b, file.c, file.d, file.e.

if any of the file.b to file.e is updated/versioned then so should file.a, even though file.a did not change the final behaviour of file.a may have changed through different behaviours in file.b to file.e which are used by file.a, therefore it is highly desireable that file.a also gets versioned/up a version+1 in case any of it's dependencies is also versioned/changed/up a version+1

Furthermore by constructing a "dependency map" it can be seen that A also depends on other files, therefore it may be desireable to update all of their versions as well, and sync them, especially if they are in the same folder, this can be a strong indicator that these files belong together and should have the same version number to describe them as a form of a package, library, module and such though more implicit perhaps.

This could be set as a rule, "versioning/sync-up" files in the same folder.

When a commit is done, all files on the dependency map get a new incremented synchronized version number, at least the files in the same folder.

Different options could be used to also allow individual versioning.

The second tool that would be necessary from compiler writers is a "change include/uses/import" tool or functionality.

Where the compiler/parser parses the files on the dependency map, then scans the files for the dependency links and replaces the existing links with the new filenames with their new version numbers.

Such that builds don't break and all files uses all other files properly such that they use the correct updated/incremented versioning number.

Such a tool could be called "Link.exe" or "LinkUp" or "LinkDependency.exe"

This would allow GIT two things:

1. Query files for links to other files.
2. Update links inside files to other files.

Basically this would allow GIT to do proper versioning numbering by for example appending version numbers to file names. To keep version numbers in sync across
related files in folders, to replace version numbers inside include/users/import statements.

This feature would be/could be more fine-grained then submodules, I have not yet used submodules, and could be weird to use submodules per file in some folder.

Plus for development environments it becomes more clear which version is actually used/opened.

Mixing of versions also becomes possible to some degree.

For example
file.a.002 could use file.b.001 and file.b.002

to transition between functionality or compare, or provide backwards compatibility and so forth.

also mixed-versions of file allows code to be upgraded more gradually instead of all or nothing.

For example some files could still use apiv1 while updated files could use apiv2 or libraryv2.

Bye for now,
Skybuck.