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.

On 27/11/2021 01:42, skybuck2000 wrote:
> < a big snip of useless stuff >
If you are so smart then work out the output of this program without
running it:
#include <stdio.h>
void f(int *p, int m)
{
    m = m + 5;
    *p = *p + m;
    return;
}
int main()
{
    int i = 5;
    int j = 10;
    f(&i, j);
    printf("%4d", i + j);
    return 0;
}
//  output = 30

On Saturday, 27 November 2021 at 01:42:27 UTC, skybuck2000 wrote:
> 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;
>
Very often you have this situation.

You have a file containing utilities. Say it's graphics, and there is a function called "ClearRect".
Another file includes the header, and calls ClearRect.

Development proceeds, and you add FillCircle to the graphics utiliites files, and to the header.

That now forces a recompile of all the files that include the utility header. However there should
be no change in behaviour. There's just a small possibility that the symbol FillCircle has been
used somewhere else.

Now obviously the utilities file needs to be marked as "updated". But should you mark all the files
which include the header as updated too?

On Monday, November 29, 2021 at 1:12:02 PM UTC+1, Malcolm McLean wrote:
> On Saturday, 27 November 2021 at 01:42:27 UTC, skybuck2000 wrote:
> > 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;
> >
> Very often you have this situation.
>
> You have a file containing utilities. Say it's graphics, and there is a function called "ClearRect".
> Another file includes the header, and calls ClearRect.
>
> Development proceeds, and you add FillCircle to the graphics utiliites files, and to the header.
>
> That now forces a recompile of all the files that include the utility header. However there should
> be no change in behaviour. There's just a small possibility that the symbol FillCircle has been
> used somewhere else.
>
> Now obviously the utilities file needs to be marked as "updated". But should you mark all the files
> which include the header as updated too?

If they belong together than yes.

For example:

graphics.h
graphics_rect.h
graphics_circle.h

They should become:

graphics_v001.h
graphics_rect_v001.h
graphics_circle_v001.h

Perhaps initially even^ could still be done later if no versioning present yet.

Then if graphics_v001.h also includes graphics_circle_v001.h then both should be updated.

However perhaps an even better plan instead of using link.exe would be to create special files called "link.map" or "dependency.map" where programmers can specify which files logically belong together, so that external tools can understand the relationship better between files.

So when one of these files is updated it changed as follows:

graphics_v002.h
graphics_rect_v002.h
graphics_circle_v002.h

So a change to any of them, is a change to all, because they belong together. Now while progamming this might become annoying, it depends on what the other files do that include them, a setting could be present that allows these files to go temporarely out of sync with each other to later sync them up again:

So while making many changes to say graphics_circle_v003,v004,v005 etc the rest stays at v001.

Then perhaps later the software can be told to re-sync these files and tell software that v005 was changed in one revision multiple times by editing programs. and needs to be squashed back down to v002... it could try and detect lowest other versions... or if any files actually use v004 and v003 if not can go back down to v002, alternatively safest thing to do is v005 especially if they are checked out multiple times or stored into different version folders. So many different possibilities how to go about it, this is why maybe depedency map file is better perhaps with some * asterix support to indicate the files in current folder belong together but just follow a certain filename pattern.

Also it would be very usefull if other software that is part of a project automatically updates it's links to these files.

So development environments should also understand which other files use these 3 files, and if these 3 files are updated in the project and versioned upwards, then all the links in the project to these files should be auto updated.

It could even be made such that the project itself/software/folder version or project version also gets auto-updated versioned upwards because this project is now using new graphics files and thus the main program/project also has changed.

Bye for now,
Skybuck.