Is your feature request related to a problem? Please describe.

• More example scenarios are needed.

• Why would you want this sub-command?

• What does it solve?

High-level description of how version systems are used by professional engineers.

Basic

• Only version source code (exceptions...)
• Do NOT version generated code (exceptions...)
• Have places for pulling and pushing generated files (or packages). (dev and prod areas)
• Version build scripts, and tool configurations
• Follow a branching model

Branches

• Use the git-flow branching model. It works for large and small products.
• main - only stable releases are committed on this branch
• develop - new code requires test, and all tests pass (process for if tests fail...)
• feature/branches - code can be checked in at any time, even if tests fail. This branch can be skipped if you are the only developer.
• release/branches - same requirements as "develop" plus all is cleaned up and packaged. The release/branch part can be skipped if you have a small team and small product. Just merge develop to main when it is stable and packaged.

Have git-proj-init create .git/hooks/pre-commit and PROJ/.pre-commit
from ~/.pre-commit or $gpDoc/hooks/pre-commit (the first one found, wins).

And have git-proj-clone create .git/hooks/pre-commit from
PROJ/.pre-commit, which should have been versioned, or use $gpDoc/hooks/pre-commit (the first one found wins).

The vars in the config files are copied between the different 'levels' (Product, User, Project, and Local). But it is not always consistent.

Cleanup: init, clone, and config

This also requires more tests to verify what is copied.

Also, the git-proj-config tests have different results between local and Action.

Ver 0.7.6
git init could make mistakes in adding too many files to the new git repo. So, provide an option to skip adding files to the new repo. That way the user can add the files they want in git.

This is needed because git doesn't always ignore the files are dirs specified in .gitignore

See issue #18

Requires: ssh-client and ssh-server.

See:
raw-ssh.md

Travis-CI's pricing plans are too confusing, and they could lead to surprising costs. I would like to do the "pay by use" plan that they describe in lots of places, but there is no plan shown for that!

From the comments in the community forum, it is clear they only want Enterprise customers, now that open-source products have hardened their product and shown it can handle large loads.

Try

• GitHub Actions - Pro: managed by GitHub. Con: there may be limits, and a future where they want $
• Jenkins - Pro: self-hosted, so always free. Con: self-hosted, and security could be an issue

Requirements:

• Run tests with changes to develop or main branches.
• Build a test package.
• Install the package.
• Verify the install.
• Push passing packages to a known location
• Remove old test packages.
• How can a RC or final package build be "signaled"?

GitHub Actions

usage-limits-billing-and-administration

• Free for public repos (with limits)
• < 20 concurrent jobs
• < 6 hours run time per job
• < 72 hours for workflows
• artifacts and log files are deleted after 90 days
• after 60 days of no activity in a repo, any scheduled workflows will be disabled

10-github-actions-resources-basics-ci-cd

Review configs looking for issues or suggested fixes.

Implement processes for a user to copy git-proj vars between
PROJ/.gitproj, PROJ/.git/config, and ~/.gitconfig, using update or
force.

Refactor pre-commit to include functions from files in ~/.pre-commit.d/ and/or PROJ/.pre-commit.d/ The functions can get their options from "git config" variables. The PROJ/.pre-commit.d/ and files would be versioned, so the PROJ/.git/hooks/pre-commit can always call them.

For example:

.pre-commit.d/
    CheckFileNames
    CheckWhiteSpace
    CheckForTabs
    CheckNotRaw
    CheckBigFiles

See issue #18

See:
raw-cvs.md
and
raw-pros-cons.md

Give examples of the command's usage, with some context, not just "standalone"
examples.

Handle files with spaces in the names.

Prompt user to change the file names?

Example problem:

/usr/lib/git-core/gitproj-init.inc: line 191: edit/obs-config/obs-studio/logs/2022-03-24: No such file or directory
/usr/lib/git-core/gitproj-init.inc: line 191: 21-18-45.txt: No such file or directory

ls edit/obs-config/obs-studio/logs
'2022-03-24 21-18-45.txt'  '2022-03-25 10-39-51.txt'  '2022-03-25 11-23-22.txt'

Create a cron job on Moria to remove all except the latest 5 test packages
from /rel/development/software/own/git-proj/deb/

See git-proj doc, and config.md

Do all, only do one or two? Some methods are not compatible. See
raw-pros-cons.md

Getting the tests set up, so they can be run on a remote server, has made the structure a bit more complex. Mainly the management of the tar files needs to be described, because they are the most fragile part to the tests.

This parameter syntax is cleaner than using multiple steps.

Make first letter lower: ${ans,}. Return first char: ${ans::1}

Input: ans="Yes" or ans="NO"

declare -l ans
ans=${ans:-n}             # default 'n'
if [ "${ans::1}" = "y" ]   # ::1 only returns the first letter

ans=${ans:-n}
ans=${ans,}                # return lower case, first letter
if [ "${ans::1}" = "y" ]

Write a script that converts "LINK{title|filepath}" to HTML anchors
or markdown links. The POD L<title|filepath> does not work for
relative links.

The absolute paths of bin and doc makes the tests to sensitive to where they are run. Remove them from the config files. The gpBin can be set to where a git-proj script is run and gpDoc can be set based on the gpBin location.

The test scripts need to have paths set to be relative to the top-git-dir for the cloned git-proj project. Test files (in the tar fiiles), should have the paths set to be relative to the directory just above the product's top-git-dir, or relative to the test's home or project dir.

Use "0" and "1", for input values, and do string tests:

if [ "${flag:-0}" = "0" ]
if [ "${flag:-0}" != "0" ]
if [ "$?" != "0" ]  # this is optional, since $? will always be an int

This is a common typo:

If "flag" is not set, or it is set to a non-integer, the following if stmt fails with a syntax error. If "flag" is not set it would be better if it was assumed to be "false"

if [ $flag -ne 0 ]; then

or this would be safer style (always define a "good" default value), but it will still have a syntax error if flag is not an integer.

if [ ${flag:-1} -ne 0 ]; then

Notice also the style for testing true/false, only "0" or "not 0" is tested. There should be no tests looking for "1" or any other value. Exception handling using error return codes would be the only exception.

A Better Solution

• Validate ALL of the vars that could be user-settable.

• Vars that are boolean values could accept, t, f, true, false, yes, no, 0, 1, and a validator would echo "true" or "false" (and return the corresponding codes), throw an error, or use a default value (with a warning). Note: Bash confuses things with return codes that are reversed from the usual 0/1 expectation: 0=OK, true, !0=problem, false.

• Vars that require specific values or a range of integers could also include some transformations, throw an error, or use a default value (with a warning).

The "setup" tar files have absolute paths in many places. Their output needs to be "patched" at run-time, just after being unpacked.

The hard part: the tar files could have been built on different systems, with different locations. So the starting path part will need to be put in each tar file, so that the patch process knows what needs to be changed.

Maintaining relative paths is really hard for an application, so absolute paths are used for things like the "origin" locations.

Maintaining absolute paths is hard for testing processes, because tests can be installed anywhere.

Add single files outside of raw/ to raw/, creating symlinks.

Support adding whole directory trees looking for binary files to be
moved to "raw" files). See function in pre-commit hook script, for
identifying those files.

If cvs is used to version raw/ files (a future enhancement), this would
be the logical place for adding raw/ files.

Increment the major/minor/path/rc/build vars based on Q/A. See See:
version-wizard.md

git-proj-clone will initially copy all of PROJ/.gitproj (after git
clone). Then update local config: local-status, local-host,
proj-name. If PROG/.gitproj is missing, recreated it from ~/.gitconfig

After cloning remote, update local vars remote-status, remote-raw-dir

When in a git or git-proj dir, config vars s/b first saved to .git/config

Do this, at the end of the command, update PROJ/.gitprog with the
gitproj values from .git/config. But these vars must stay set to TBD,
in .gitproj: local-status, local-host, proj-name, remote-status,
remote-raw-dir

For good TDD, the tests should only test at the topmost interface or function inputs and outputs.

Tests for internal functions should be moved to a different test area. I.e. they are optional; they are only used when the functions are first created. Refactoring could remove or change internal functions. The important part is testing the interface inputs and the expected outputs, not how the internal functions work.

I build these, so I can put the deb packages in the released area on moria.
Then pull them down if needed.

Describe the bug

Upper-case in config var names could break the code with unexpected names.

Desktop (please complete the following information)

• OS and OS Version: MX 19

• Version: 0.5.4

Additional context

Fix the 'git config' related functions to lowercase the section and key names.

See git-proj doc, and config.md.

Implement

• if env. var not set, read var from ~/.gitconfig, PROJ/.git/config,
  giving a "default" if var is not defined.

• CLI option will override env. var.

• Validate the settings, if any error, exit

• Copy the test-env*.tgz files to a "public" place. And implement the
  Makefile targets for managing them.

To support a fully distributed git reop along with a distribute raw repo, allow the user to define more than one remote.

Keep the raw remote paired with the git remote.

If a raw/ dir already exists, then skip looking at those files.
Ver 0.7.6

Files that are in ignorefiles should also be ignored in the search for large files, because they will not be added to the initial git repo (i.e. they better not be added).

"mkdir raw" should be skipped if it exists.

Existing files in raw/ should not be replaced with any moves. An error should be thrown.

See issue #18

See
raw-rclone.md

fComGetConfig is doing too many things that are not
used. (e.g. listing source)

See issue #18

Use a process similar to rsnapshot. For details see:
raw-rsnapshot.md
and
raw-ssh.md