Releases: raven42/dotfiles
v2.0.1
Release Notes
Rework the GIT_REPO/etc environment variables to be based on entering directories. This works far better for submodule repositories to help make sure repository membership is maintained.
The major reworks of this is to reduce the reliance on the git-repo subshell environment, and instead update the environment variables when entering a directory that contains a git repository. This is needed when working with submodules to ensure that the appropriate environment variables are set and git ... commands can be issued to the appropriate repository.
For example in the v1.0 implementation, issuing the git-repo <repo> would put you into a subshell with the GIT_WORKTREE environment variable set to the root repository. However if you were to enter a submodule, then running git ... commands would get confused as to which git repository to run them on.
Git Environment Variables
Reworking this allows us to avoid using the GIT_WORKTREE environment variable at all, and only set the GIT_ROOT/GIT_REPO/GIT_DIR where needed. Specific use of GIT_DIR should be avoided as well whenever possible as this is also used by git and other applications (vscode).
This handling is now mostly all managed inside the sbin/git-environment.bash shell resource file.
The following environment variables are now set / modified as directories are left/entered:
GIT_ROOT: This always points to the top most repository root. Even when inside a sub-module. This value will be unset if not in a valid git repository.GIT_REPO: The repository name of the active repository. Changes as the active repository changes. This will point to the repository name of the sub-module if entering a sub-module of another repository. This value will be unset if not in a valid git repository.GIT_PATH: The directory where the current GIT_REPO repository is located. This value will be unset if not in a valid git repository.GIT_SUPERPROJECT: Only valid if within a sub-module of another repository. This will be set to the root path of the parent repository. Note: If there are multiple nested sub-modules, it will only point one repository up. This value will be unset if not in a submodule.GIT_REMOTE: This will be the repository name of the remote.- XXX: DON'T TOUCH $GIT_DIR!!!: Other programs use this and so it should be left to operate on it's own according to how git normally manages this.
change_dir shell function
To help accommodate this, the change_dir shell function has been modified. This will now trigger updates to the git environment variable instances as well as re-computing aliases. This is managed in the sbin/change_dir.sh shell resource file.
Because of the updating of the resource files, it is now desireable to ensure this shell function is used for aliases that change directories. To do this, the following code should be added to any aliases:
if [[ $(type -t change_dir) == function ]]; then
CD=change_dir
else
CD=cd
fi
alias dir1="$CD <path>"Aliaes
This also reworks the expected usage of .private/common_rc.sh and introduces a new .private/aliases.sh. The separation is to avoid duplication of extra processing in the common_rc.sh resource file. The idea is that all aliases that are git repository specific should go in the aliases.sh. This aliases file is sourced every time a git repository is changed. This included entering a new git repository or a submodule repository.
For your convenience, both the parent repository and submodule (if available) are tracked. The GIT_ROOT environment variable will always be set to the parent repository. So if you want aliases that are full paths within the parent repository, the aliases should be defined like this:
alias dirAlias1="$CD $GIT_ROOT/<path>/<to>/<dir>"
If you want the alias to be relative to whichever git repository you are in (including submodules), then the alias should be defined as follows:
alias dirAlias2=$CD $GIT_PATH/<path>/<to>/<dir>"
v2.0-beta
Release Notes
Rework the GIT_REPO/etc environment variables to be based on entering directories. This works far better for submodule repositories to help make sure repository membership is maintained.
The major reworks of this is to reduce the reliance on the git-repo subshell environment, and instead update the environment variables when entering a directory that contains a git repository. This is needed when working with submodules to ensure that the appropriate environment variables are set and git ... commands can be issued to the appropriate repository.
For example in the v1.0 implementation, issuing the git-repo <repo> would put you into a subshell with the GIT_WORKTREE environment variable set to the root repository. However if you were to enter a submodule, then running git ... commands would get confused as to which git repository to run them on.
Git Environment Variables
Reworking this allows us to avoid using the GIT_WORKTREE environment variable at all, and only set the GIT_ROOT/GIT_REPO/GIT_DIR where needed. Specific use of GIT_DIR should be avoided as well whenever possible as this is also used by git and other applications (vscode).
This handling is now mostly all managed inside the sbin/git-environment.bash shell resource file.
The following environment variables are now set / modified as directories are left/entered:
GIT_ROOT: This always points to the top most repository root. Even when inside a sub-module. This value will be unset if not in a valid git repository.GIT_REPO: The repository name of the active repository. Changes as the active repository changes. This will point to the repository name of the sub-module if entering a sub-module of another repository. This value will be unset if not in a valid git repository.GIT_PATH: The directory where the current GIT_REPO repository is located. This value will be unset if not in a valid git repository.GIT_SUPERPROJECT: Only valid if within a sub-module of another repository. This will be set to the root path of the parent repository. Note: If there are multiple nested sub-modules, it will only point one repository up. This value will be unset if not in a submodule.GIT_REMOTE: This will be the repository name of the remote.- XXX: DON'T TOUCH $GIT_DIR!!!: Other programs use this and so it should be left to operate on it's own according to how git normally manages this.
change_dir shell function
To help accommodate this, the change_dir shell function has been modified. This will now trigger updates to the git environment variable instances as well as re-computing aliases. This is managed in the sbin/change_dir.sh shell resource file.
Because of the updating of the resource files, it is now desireable to ensure this shell function is used for aliases that change directories. To do this, the following code should be added to any aliases:
if [[ $(type -t change_dir) == function ]]; then
CD=change_dir
else
CD=cd
fi
alias dir1="$CD <path>"Aliaes
This also reworks the expected usage of .private/common_rc.sh and introduces a new .private/aliases.sh. The separation is to avoid duplication of extra processing in the common_rc.sh resource file. The idea is that all aliases that are git repository specific should go in the aliases.sh. This aliases file is sourced every time a git repository is changed. This included entering a new git repository or a submodule repository.
For your convenience, both the parent repository and submodule (if available) are tracked. The GIT_ROOT environment variable will always be set to the parent repository. So if you want aliases that are full paths within the parent repository, the aliases should be defined like this:
alias dirAlias1="$CD $GIT_ROOT/<path>/<to>/<dir>"
If you want the alias to be relative to whichever git repository you are in (including submodules), then the alias should be defined as follows:
alias dirAlias2=$CD $GIT_PATH/<path>/<to>/<dir>"