nsensfel / git-submodules Goto Github PK

1.0 1.0 0.0 178 KB

Git Submodule alternative with equivalent features, but easier to use and maintain.

License: Apache License 2.0

Python 100.00%

git git-submodule git-submodules submodule submodules

git-submodules's Introduction

Welcome to my GitHub profile

I am currently looking for a career opportunity in software development for projects in the European space industry. Here's my LinkedIn account, and my personal website.

The collection of repositories here is mostly restricted to projects I do in my spare time. These do not generally involve anything related to embedded systems programing, as I do not wish to be working on the same challenges at work and at home.

Below is a list of projects I am currently working on. Do not be fooled if GitHub indicates that the last commit was made a while back: it doesn't account for branches, and I tend to make very long branches which I merge back into master only when I deem the branch's feature has been fully completed.

relabsd

Daemon that turns your input devices into joysticks by converting relative axes into absolute ones. It was originally intended as a tool to allow the use of the SpaceNavigator (a 3d mouse, which is definitely an oddity) as a 6 directional joystick (something supported by every input library), but I made it generic enough that it can be used for other purposes.

Website: Not available yet.

Related repositories: main repository

Compiler and languages for narrative orchestration of interactive media.

Coded in Java.

This is an alternative to Inkle's Ink and Yarn Spinner: a language allowing you to easily describe the narrative of a game, which is then interpreted by the game engine to present the player with scenes, characters, dialogues and reply options.

Tonkadur distinguishes itself by not using just a single language, but two: Fate and Wyrd.

Fate is what one would expect for narrative scripting (with some extra bells and whistles, of course). It's a strongly typed language with clear LISP and C inspirations. The objective for Fate is to provide the user with as much tool as they need to concisely describe their narrative, while also providing tools to greatly reduce the risks of mistake. It goes beyond what is usually available for this type of language, with reference manipulation, lambda functions, loops, and structures.

Wyrd is closer to a RISC assembly language. Very few instructions are available when writing in Wyrd, and it's a good thing: the objective here is to make it extremely easy to add support for Wyrd to an existing engine. Tonkadur simply compiles Fate to Wyrd, allowing users to have access to a very large array of instructions when writing while not having to worry about the implied complexity this adds to properly supporting the language.

Of course, this comes with a price: performance is not as good as if Fate was interpreted directly. However, in the context of narrative scripting, WCET is not exactly considered a critical factor.

This project is meant to be used in Tacticians Online, but as with Ataxia, it is completely separate and can be used by anyone.

Website: https://tonkadur.of.tacticians.online/

Multiplayer browser game.

Server coded in Erlang, client coded in Elm. Playable demo available at https://tacticians.online, except when my dying router has a breakdown.

Creating a multiplayer game is always a nice, endless source of challenges. It might not get down to low-level programming, but it does involve tackling issues from a wide range of programming fields that complement those I handle at work, be it networking, database management (see my Ataxia project), GUI, procedural asset creation, multi-threading, web development, or system administration.

While this is a pet project, I do take it seriously and learn about legal procedures/obligations in order to ensure its success, be it data privacy laws or trademarks (which I registered in both the EU and the US).

Website: https://tacticians.online

Ataxia

Distributed NoSQL database for Erlang.

Coded in Erlang. Still missing the most important features.

This is meant to be the database interface for Tacticians Online. The targeted environment is that of a large collection of heterogeneous small servers (e.g. some cheap ARM development boards) interconnected by some pretty basic Ethernet (so bandwidth usage is the main scalability limiter). The whole database has to be kept consistent even when a transaction fails (well, the whole ACID properties are meant to be verified) as well as when a node goes down (those are cheap boards, after all).

It uses its own language for queries, where the user basically builds the abstract syntax tree of a function to either select of modify a particular item.

This project is still in its early stages of development. Indeed, the whole "distributed" and "fault-tolerance" parts are still missing. I do already use it for Tacticians Online though, with it running on a single node with all the limitations that I expect will end up being required in its final form (e.g. each query can only access a single entry).

Website: Not available yet.

Related repositories: main repository.

JabberHive

Distributed Markov-chain based reply-bot.

Coded in C and Python.

Construct a reply-bot by networking program nodes. These nodes are split into three categories:

Gateways, which interact with things other than JabberHive (e.g. IRC, Discord, or the command line).
Filters, which transform JabberHive queries and answers.
Servers, which store knowledge and perform the Markov-chain sentence generation.

Website: https://jabberhive.org/

Related repositories: See related tag.

git-submodules's People

Contributors

Stargazers

Watchers

git-submodules's Issues

Add `rm` command

Add the rm command, that removes both the directory and the description for the submodule. Ask confirmation if no target path is given.

Add `seek` command

Add a seek command that lists all directories that could be added as submodules.
In effect, recursively enter each directory starting from the repository's root, keep on going deeper until the current directory is a repository. Do not print those that are already registered as submodules.
It should then be possible to use the following command to automatically add all possible submodules:

$ git-submodules.py add `git-submodules.py seek`

Add `to-official` command

Add a to-official command that transforms all submodules into Git Submodules. This is likely to be challenging, since if that was simple, the git-submodules tool wouldn't have much of a reason to be there.
Beware of git-submodules that were previously Git Submodules and weren't turned into regular repositories beforehand.
At first glance, the steps to take are going to be:

Retrieve path list of all Git Submodules in the repository.
Remove from the repository all Git Submodules whose path was targeted by the to-official command.
Find a source that supports the target commit (Is that doable without cloning the repo?) for each target path.
Add a Git Submodule to the repository for each target path using the aforementioned source.

Add `list` command

Lists all submodules or the submodules in the directories given as parameter.

Switch to a more user-friendly .gitsubmodules update process

Currently, any automated update to the .gitsubmodules file results in all its content being entirely replaced. This scraps any comments or extra things the user might have added.

It would be much better if the update process kept all that and just modified and appended
what it needs to.

Add support for branch & tag target hint

Currently, submodules use the commit key to determine which version to use. This should not change. However, an additional configuration key could be used to indicate if that targeted commit is outdated/incorrect.

target = commit: just use the commit (default).
target = branch NAME_OF_BRANCH: Check if the commit is the most recent one on that branch. If it isn't, a warning should be printed when running status or using the description to update or generate the submodule's repository.
target = tag NAME_OF_TAG: Check if the tag matches the commit. If it doesn't, a warning should be printed when running status or using the description to update or generate the submodule's repository.

If target is set to either branch or tag, the status command must fetch remote changes prior to running.

Add 3 commands:

desc-match-target: which updates commit in the description to match what target indicates.
dir-match-target: updates the submodule's working tree to match what target indicates.
match-target command: desc-match-target then dir-match-target.

Add support for named sources

The configuration file would then have:

source = URL adds an anonymous URL to clone the repository. Multiple instances of that key means that each indicated URL can be used.
source.name_of_source = URL adds a named source, which can be used to clone the repository, but is also added as a remote after cloning. Multiple instances of a identically named source.name_of_source key means that only the last one is considered.

Missing Documentation

Most commands and the .gitsubmodules format are undocumented.

Add `foreach{,-enabled}{,-recursive}` commands

These commands define the following environment variables while executing the command:

$SNSM_ROOT absolute path of the root repository.
$SNSM_PATH relative path of the submodule.
$SNSM_COMMIT commit target of the submodule.
$SNSM_ENABLED is 1 if the submodule is enabled, 0 otherwise.
$SNSM_SOURCES is a space separated list of the submodule's sources.

The commands would then be:

foreach: last "path" is a string corresponding to a command to run on all targeted paths. The command is ran from the repository's root directory.
foreach-enabled: foreach, but only for enabled submodules.
foreach-recursive: foreach, but after applying the command to a submodule, it also recurses into each repository and applies a foreach-recursive as if it had been executed in the repository of that submodule.
foreach-enabled-recursive: foreach-recursive, but only for enabled submodules (including during the recursion).

Set `target` automatically when adding submodule

Currently, the target parameter of any newly added submodule is set to commit.
It would be preferable to set it to the currently used branch is the working directory is currently on a branch and to commit only if it is on a detached commit.

Add `match-target` command

The command is equivalent to:

update-directory as if target_overrides_commit = 1.
update-description.

Add support for split submodule descriptions.
Line parsing regexes should ignore anything commented out.