-
Notifications
You must be signed in to change notification settings - Fork 0
Mostly like plain old git, except recurses into one level of submodules.
License
digitalplaywright/smgit
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
Mostly like plain old git, except recurses into one level of submodules. There's not really anything magic about this script. For the most part, it just executes the given command in each submodule directory and then in the top-level ROSE repository. It can be invoked from any directory under ROSE (either in the ROSE repository or one of the submodules). SPECIAL COMMANDS A few git commands get special handling by this script in order to restrict their functionality or to extend it to do something more useful in an environment with submodules. clone After cloning the main repository, it initializes submodules, gives the user a chance to change their URLs (if the --edit switch is given), and then updates the submodules. These switches are supported: --edit (not a Git switch, but controls whether the user is given a chance to modify submodule URLs), --quiet, --verbose, --no-hardlinks, --branch, --templates, and --upload-pack. The following switches don't make sense in this environment: --shared, --reference, --no-checkout, --bare, --mirror, --origin, --depth. The switch --recursive is not accepted since the behavior is to always recurse into submodules. checkout Checks out the specified branch (after optionally creating it) in the main repo and then updates all submodules. Furthermore, if a submodule has a suitable branch, that branch will be checked out in the submodule. See CHOOSING SUBMODULE BRANCHES for details. These switches are supported: --quiet, -b, --track, --no-track, and -l. The following switches don't make sense in this environment: --force, --ours, --theirs, --merge, --conflict, and --patch. branch Lists, creates, deletes or renames branches in the main repository and all submodules. When creating a new branch the specified branch head (if any) is the one defined in the main ROSE repository. The head of the new branch in the submodules will be chosen according to the commit registered in the branch head of the main ROSE repository. In other words, in the main repository "newbranch" will point to the same commit as "base", while in the submodule, "newbranch" will be created to point to the commit that is referenced by the submodule directory in the "base" commit of the main repository. $ smgit branch newbranch base All git-branch switches are supported, namely: -d, -D, -l, -f, -m, -M, --color, -r, -a, --verbose, --abbrev, --track, --contains, --merged, and --no-merged. commit Commits changes that are staged for committal, first in the submodules and then in the main repository, using a single commit message. These switches are supported: --all, --reuse-message, --reedit-message, --reset-author, --file, --author, --message, --templates, --signoff, --no-verify, --cleanup, --edit, --untracked-files, --verbose, and --quiet. These switches are not supported since they either don't make sense in this environment or are difficult to implement: --allow-empty, --amend, and --dry-run. merge Merges one branch into another by first merging in the main repository (ignoring conflicts for the time being), then merging in the submodules, then adding new submodule versions to the main repository, then committing the changes in the main repository if necessary and possible. These switches are supported to varying degrees: --ff, --no-ff, --log, --no-log, --stat, --no-stat, -n, --ff-only, --quiet, --verbose, and -m. These switches are not supported: --commit, --no-commit, --squash and --no-squash. The default is that merges are always committed. debug Prints some information about the repository that is useful for debugging problems with smgit. CHOOSING SUBMODULE BRANCHES When a branch is checked out in the main repository, we update the submodules so their heads are pointing to the commit specified in the main repository. Furthermore, if a submodule has a suitable branch, we check out that branch in the submodule rather than leaving the head in a detached state. If the parent's branch name is B and the parent is pointing to submodule commit C, then here's how the branch is chosen in a submodule: 1. If the submodule has a branch named B that is pointing to commit C, then we check out branch B. 2. Otherwise, if the submodule has a branch named origin/B that points to commit C, we do one of the following if their preconditions are met: A. If the submodule has no branch named B then branch B is created as a tracking branch of origin/B and is checked out. B. If branch B exists and can be fast forwarded to origin/B then we check out B and fast forward to origin/B. 3. Otherwise, if the submodule has any local or remote branch that points to commit C we arbitrarily choose one. If the chosen branch is a local branch we use case 1 above, otherwise we use case 2 above. 4. Otherwise, the head of the submodule remains in a detached state. OTHER COMMANDS All other commands are identical to Git and are executed first in the submodules and then in the main ROSE repository.
About
Mostly like plain old git, except recurses into one level of submodules.
Resources
License
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published