Distributed Git Workflow Management Tool - The Git Replacement for the "Awesome" PARSEC Environment
.grapeconfig fileTo write a sample .grapeconfig file with the settings for grape in your current environment:
grape writeConfig sample.grapeconfig
sample.grapeconfig now contains all of the options various grape commands will use. It’s of the following format:
[SECTION_NAME]
option = value
option2 = key:value
option3 = list:of key:values with:VAL as:a default:value ?:VAL
In the man page for any given grape commands (viewable by typing grape
[default = .grapeconfig.SECTION_NAME.option]
This means that that option grabs it’s value from the .grapeconfig file for your project by default.
If you’re a project maintainer, this .grapeconfig stuff really matters for how you want your team to work.
If you’re a lowly peon, err… valued developer, you don’t care. You’re reading this because your project
maintainer has set you up with grape and wants you to use it for branch creation, library maintenance,
testing stuff before publishing it, doing the correct git incantations to merge branches in a way that
makes sense for your team, etc. The lowly peo–, excuse me, Valued Developer view of grape should be:
# take a look at available commands
grape
# create a new branch, such as a feature or a bugfix branch (your team's branch names may differ)
grape <branchType>
# <do work>
gvim foo.txt
# add a file using git commands
git add foo.txt
# inspect the status of your work across all subprojects:
grape status
# commit to your local repo all staged changes in all subprojects
grape commit
# Update your topic branch with recent changes on the destination public branch
grape md
# publish your branch to the appropriate public branch (e.g. master, develop, release, etc)
grape publish
Almost all of those grape commands have more options associated with them, which you can inspect by typing
grape <cmd> --help
And that’s all you valued developers need to know! Project maintainers, read on!
If your project is simple, with a single repository and no submodules or subtrees with third party
libraries, then this section should be all you need. Read on for more advanced topics as they come up.
This assumes you have a git repository set up, have at least a rudimentary knowledge of git,
you have an idea of how you want to do your branching (single trunk, gitflow, or some other weird thing),
and you are ready to distribute your well thought-out process using grape.
Much of grape also assumes you’re working in a clone of a repo, with a remote called origin.
This tutorial assumes you’re developing in a project called foo hosted at a bitbucket instance
at https://bitbucket.grape.tutorial.org, and that you’re planning to use a two-trunk development model, with both a
develop branch and a master branch.
Ok, let’s go to your git repository, and create an initial grape config file.
cd /path/to/repo
grape writeConfig .grapeconfig --gitflow
Let’s open up that .grapeconfig and edit some config options so that they make sense.
[repo]
name = repo_name_not.yet.configured
url = https://not.yet.configured/scm/project/unknown.git
httpsbase = https://not.yet.configured
sshbase = ssh://[email protected]
For repo.name, put in your project name. Fill out your default url, (either ssh or https), as well as
the https base url and bitbucket url:
[repo]
name = foo
url = https://bitbucket.grape.tutorial.org/scm/foo/foo.git
httpsbase = https://bitbucket.grape.tutorial.org/scm/
sshbase = ssh://[email protected]:1111/foo
Take a look at the [flow] section. This is probably one of the most important sections in your .grapeconfig file,
as it defines your project’s branching model.
[flow]
publishpolicy = ?:merge master:cascade->develop
publicbranches = master develop
topicprefixmappings = hotfix:master bugfix:develop feature:develop ?:develop release:develop
topicdestinationmappings = release:master
The publicbranches is a space-delimited list of all of your long-lived public branches. These are typically things
like develop, master, or release2.0, but can be whatever your project thinks makes sense.
The topicprefixmappings determines the start point for your topic branches. It is a space-delimited list of key:value
pairs, where the key is a branch prefix, and the value is the public branch topic branches with that branch prefix.
The ?:develop option means that any branch that isn’t named with feature, bugfix, or hotfix as a prefix will be assumed
to branch off of develop.
For each branch type you define in topicprefixmappings, grape will dynamically generate a new command for creating
new branches of that type. So, in the above case, grape feature, grape bugfix, and grape hotfix will all be
available as commands.
The publishpolicy is another list, but it maps PUBLIC branches to merge policies. So, if you’re on a rebasing kind of
team, choose ?:rebase. If you’re a merge kind of team, choose ?:merge. If you want to squash-merge your commits to
master to keep history clean there, but preserve all the churn on develop, do something like the following:
[flow]
...
publishpolicy = master:cascade->develop develop:merge ?:merge
If you don’t know what we’re talking about here, just leave it as is. It preserves fine grained history on the develop
branch, but has nice clean history on master.
topicdestinationmappings is similar to topicprefixmappings, but it acts to override where a branch is published to. In
gitflow land, this enables release branches - branches that start in develop (as described in topicprefixmappings) and
get published to master.
###A note for Windows compatibility
If you’re on a system where ‘git’ is not in your path (often true on Windows systems), you’ll want to add the following
to a .grapeconfig file in your home directory:
[git]
executable = /path/to/your/git/executable/git.exe
where the format of the path is whatever is appropriate for your system. You may need to do this by hand before ever
calling grape.
When your valued developers want to publish their invaluable work to a public branch, your team may have a host of
SQA driven requirements, such as successful build(s), testing, etc. You’ll want to take a look at grape publish --help for more details on this, but for now let’s look at a few key things in the [publish] section of your
.grapeconfig file.
[publish]
buildcmds =
builddir = .
testcmds =
testdir = .
prepublishcmds =
prepublishdir = .
postpublishcmds =
postpublishdir = .
tickversion = False
useStash = True
deletetopic = False
updatelog = .grapepublishlog
logskipfirstlines = 0
logentryheader = <date> <user>
emailnotification = False
emailheader = <public> updated to <version>
emailserver = smtp.email.server
emailsendto = [email protected]
emailsubject = <public> updated to <version>
Ok, there’s a lot here. But that’s because publish can do a lot for you, I promise.
buildcmds : This is a COMMA-delimited list of commands you use to build your code.
builddir : This is the directory where the buildcmds are issued from, relative to your repository’s base directory.
testcmds and testdir: Same as buildcmds and builddir, but for running your project’s tests.
Have other custom steps in your process? Make use of prepublish[cmds|dir] and postpublish[cmds|dir] to customize your
process.
If you keep a running change log, you’ll want to take a look at the grape publish documentation, paying attention to
updatelog, logskipfirstlines, and logentryheader. If you send email notifications, check out all the documentation
for all the email-related options as well.
If you manage your code reviews using Pull Requests on Bitbucket (formerly known as Stash), and you want to enforce the existence of approved pull
requests for each branch being published, leave useStash as True. Otherwise, set it to False.
What about that tickversion option? Set it to True if you want to auto-increment your project’s version with grape.
Check out grape version --help for more info on managing versioning your project with grape.
If you’d like to manage third-party library source-code inline with your project, git provides a couple of ways
to do it: Submodules and Subtrees. GRAPE provides yet one more way to manage subprojects - dubbed a nested project.
Googling submodules vs. subtrees will yield discussions as vehemently
idealogical as emacs vs. vim or git vs. perforce or merge vs rebase. Grape’s philosophy is not to discriminate
based on religion, so it aims to make life easier regardless of your decision, and to hide inherent complexities
associated with both as much as possible. That said, here is our take on situations appropriate for submodules vs
situations more appropriate for subtrees:
Google it for details on the technical differences. Keep in mind as you read forums that a lot of the negative
side effects of both are mitigated by grape, athough the submodule functionality is perhaps more fully flushed
out than the subtree functionality at the current stage of development. That said, the internet probably leans
toward subtrees. In any case, there are still situations where you definitely want one vs. the other, listed
below.
A nested subproject is managed completely by grape - your outer level git repository has no awareness of it. This means
you can use nested subprojects for things like
We assume that you’re using submodules or subtrees as a means to manage pedigree of your code - when you check out
version 1.2 of your project, you want to make sure you can always build it with the versions of third party libraries
you had when you developed version 1.2. We also assume you need to make changes to the third party libs as a regular course of
business (e.g. portability fixes), and that such changes are expected to be reviewed in the context of changes to
your project.
A natural model for this is to have each library be its own repository, either a fork of that library’s official git
repo, or a hand rolled one based off of snapshots that your project maintains. Grape assumes that for each of your
public branches in your project, there is a consistently named branch in each of your subprojects. For example,
for your project foo that depends on third party library libBar, foo might have the branches develop and master, and
libBar might have the branches foo_dev and foo_master.
Using this model allows one to merge in updates to the third-party codebase with your changes in a natural way. If
desired, it enables relative easy contributions of your fixes to the library when appropriate.
Currently grape doesn’t support recursive subprojects. This doesn’t matter too much for subtrees, but for submodules
it might matter a great deal.
.grapeconfig[workspace]
subprojecttype = submodule
managesubmodules = True
submoduletopicprefixmappings = ?:develop
submodulepublishpolicy = ?:merge
submodulepublicmappings = ?:master
subprojecttype is used when adding new subprojects, and can be set to either subtree (Default), submodule, or nested.
managesubmodules should be set to True to enable grape managed subprojects. Otherwise, you’re on your own.
submoduletopicprefixmappings is analogous to flow.topicprefixmappings. When you publish changes in your project,
this is what grape uses to determine which branch in your submodule updated submodules’ changes get merged to.
submodulepublishpolicy is analagous to ‘flow.publishpolicy’, but determines what merge rebase action will take
place in your submodules.
submodulepublicmappings is a list of key:value pairs that define the association of your project’s public branches
to your submodule’s public branches, e.g. develop:foo_dev master:foo_master.
When you create and checkout a branch in grape using grape
out in your submodules as well, using workspace.submodulepublicmappings[flow.topicprefixmappings[
determine your submodules’ branch’s start points.
For example, with the following .grapeconfig:
[flow]
topicprefixmappings = bugfix:develop hotfix:master feature:develop ?:develop
[workspace]
managesubmodules = True
submoduletopicprefixmappings = feature:foo_dev bugfix:foo_dev hotfix:foo_master
submodulepublicmappings = develop:foo_dev master:foo_master
calling grape bugfix will create a new branch off of develop in project foo, and a branch of the same name off of
foo_dev in submodule libBar.
grape statusGrape status will gather the status across all submodules and nested projectes and your outer-level project. This is different
from git status, which will only give you the status of the repo / submodule / nested project you are currently in.
grape commitGrape commit will commit all changes in submodules and nested subprojectes first, then perform the commit in the outer level repository to
ensure you have updated the gitlink for your submodules.
grape pushGrape push pushes changes in your current branch to origin in all submodules and your outer level repository.
grape mdGrape md handles the situation where you’re merging in changes to a submodule in a branch that also has changes in
that submodule. This normally is a guaranteed conflict in the gitlink, even if the appropriate merge in the submodule
should be clean. In the above example, while on a branch called feature/user/descr this performs the following steps:
in foo:
git merge develop
on conflict:
in libBar:
git merge foo_dev
on conflict:
ask user to resolve
in foo:
resolve gitlink conflicts
if still in conflict:
ask user to resolve
commit result of merge
Use grape md --continue once you’ve resolved any conflicts generated by this process.
grape publishGrape publish will perform the merge actions as defined by workspace.submodulepublishpolicy in all submodules first,
then publish your outer level repo.
grape reviewWhen creating a new pull request with a description, grape will create pull requests in all modified submodules and
append links to those pull requests in your project-level pull request.
grape dbWhen deleting a branch, grape will delete branches of the same name in your submodules.
Grape uses git-subtree, which is part of the contrib/ section of the official git repository. You’ll need to install
git-subtree for grape’s subtree features to work.
.grapeconfig sections[subtrees]
mergepolicy = nosquash
pushonpublish = False
names = libBar
[subtree-libBar]
prefix = imports/libBar
remote = ../libBar
topicprefixmappings = ?:
Check out the grape addSubproject --help for more details. When you use addSubproject, grape updates the .grapeconfig
file as appropriate.
grape publishGrape can be configured to split-push changes in subtrees to their host repository as part of your publish step by
setting subtrees.pushonpublish to True.
A nested subproject is a git repository that is ignored by git, but grape manages things like branch consistency, publish
actions, gathering information with status, etc. Individual developers decide whether they want the nested subproject in
their workspace by using ‘grape uv’.
Grape uses the .grapeconfig to know what nested subprojects are available to developers, and then the .git/.grapeuserconfig
to know which ones to expect to find in the user’s workspace.
nested projects are currently supported by addSubproject, uv, status, checkout, and commit. Notable lack of support at
the moment includes publish, merge actions (m, mr, and md), and foreach.
.grapeconfig sections[nested]
names = libBar
[nested-libBar]
prefix = imports/libBar
remote = ../libBar
All of these are analagous to the same named options in the subtrees and subtree-libBar counterparts.
.grapeuserconfig sections[nested-libBar]
active = True
The active flag is what grape uses to determine if the nested subproject should be in your workspace. Note that grape will
only look in .git/.grapeuserconfig for this particular setting, since the intended use cases for nested projects tend to be highly
individualized.
Below is the most detailed documentation that currently exists for each of the grape commands. You can always look
at a particular commands documentation using grape
Some commands are better documented than others, but our use of the docopt.py module guarantees that all available
options are at least listed below.
grape addSubproject
Adds a new project to this workspace (such as a new library or a new test suite)
Usage: grape-addSubproject --name=<name> --prefix=<prefix> --url=<url> --branch=<branch>
[--subtree [--squash | --nosquash] | --submodule | --nested]
[--noverify]
Options:
--name=<name> The name of the subproject.
--prefix=<prefix> Path to place the subproject in your current workspace. (Relative to the top level
directory in your workspace.)
--url=<url> The URL (SSH, HTTPS, or Relative URL) of the new project's repository.
--branch=<branch> The branch name of the subproject you want to add.
--subtree Add this subproject as a subtree. Default behavior if .grapeconfig.workspace.subprojectType
is subtree.
--squash For subtree projects, if --squash is used, will add <commit> as a squash merge.
This defaults to true if .grapeconfig.subtrees.mergePolicy is squash.
--nosquash For subtree projects, if --nosquash is used, will ensure full history of <branch> is merged
in.
--submodule Add this subproject as a submodule. Default behavior if
.grapeconfig.workspace.subprojectType is submodule.
--nested Add this subproject as a nested git project. While in the main repository, git will ignore
all activity in this subproject. GRAPE commands such as checkout, status, and commit will
act across all nested subprojects in much the same way as grape manages submodules.
--noverify Set to prevent grape from asking for user verification before adding the subproject.
grape bundle uses the 'git bundle' feature to extract a subset of history into a git bundle file,
which can then be sent over a sneakernet to a mirror of your grape project.
The history range that is extracted is defined in the following way:
start point:
for each branch in <list> as defined by --branches, start at the commit tagged by
<tagprefix>/<branch>.
end point:
the tip of each branch in <list> as defined by --branches.
By default, grape bundle bundles up all active submodules in your repository, according to their
respective .grapeconfig files.
Usage:
grape-bundle [--noRecurse] [--branches=<config.patch.branches>]
[--tagprefix=<config.patch.tagprefix>]
[--describePattern=<config.patch.describePattern>]
[--name=<config.repo.name>]
[--outfile=<fname>]
[--bundleTags=<branchToTagPatternMapping>]
[--submoduleBranches=<config.patch.submodulebranches>]
Options:
--noRecurse bundle only current level
--branches=<list> the space delimited list of branches to bundle.
[default: .grapeconfig.patch.branches]
--tagprefix=<str> the prefix used to tag start points to bundle
[default: .grapeconfig.patch.tagprefix]
--describePattern=<pattern> passed to git describe to aid in naming the bundle.
[default: .grapeconfig.patch.describePattern]
--name=<str> Name used as a prefix to the bundle file.
[default: .grapeconfig.repo.name]
--outfile=<fname> Name of the output bundle file. Default behavior is to
use branch names, the repo name, and output of git-describe
to construct a name. Note that the default file name carries
semantics for grape unbundle in determining which branches to
update.
--bundleTags=<mapping> A list of branch:tagPattern tags to bundle. Note that a broadly defined tag
pattern may yield larger bundle files than you might expect.
[default: .grapeconfig.patch.branchToTagPatternMapping]
--submoduleBranches=<list> space delimited list of submodule branches to bundle.
[default: .grapeconfig.patch.submodulebranches]
.grapeConfig Defaults:
[patch]
branches = master
tagprefix = patched
describePattern = v*
submodulebranches = master
[repo]
name = None
grape unbundle
Usage:
grape-unbundle [--branchMappings=<config.patch.branchMappings>]
[--submoduleBranchMappings=<config.patch.submoduleBranchMappings>]
[--noRecurse]
Options:
--branchMappings=<pairlist> the branch mappings to pass to git fetch to unpack
objects from the bundle file.
[default: .grapeconfig.patch.branchMappings]
--submoduleBranchMappings=<pairlist> the branch mappings to pass to git fetch to unpack
objects from the bundle file.
[default: .grapeconfig.patch.submodulebranchmappings]
--noRecurse do not recurse into submodules and nested subprojects
Usage: grape-status [-u | --uno]
[--failIfInconsistent]
[--failIfMissingPublicBranches]
[--failIfBranchesInconsistent]
[--checkWSOnly]
Options:
--uno Do not show untracked files
-u Show untracked files.
--failIfInconsistent Fail if any consistency checks fail.
--failIfMissingPublicBranches Fail if your workspace or your origin's workspace is missing public branches.
--failIfOnInconsistentBranches Fail if your subprojects are on branches that are inconsistent with what is checked out in your workspace.
--checkWSOnly Only check the workspace's projects' branches for consistency. Don't gather git statuses.
grape stash can run simple git stash, git stash pop, or git stash list commands in all repositories
in your workspace.
Note that this is a bit scary - a simple git stash pop will attempt to apply the most recently stashed
commit in each repo, grape makes no attempt of tracking of which commits were stashed on the most recent
call to grape stash, so if you do a stash with active edits in one repo, then later do a stash with
active edits in another repo, then grape stash pop will trigger pops in both repos, in a sense breaking First-In-Last-Out semantics that one might expect.
Usage: grape-stash
grape-stash pop
grape-stash list
grape checkout
Usage: grape-checkout [-b] [--sync=<bool>] [--emailSubject=<sbj>] [--updateView] [--noUpdateView] <branch>
Options:
-b Create the branch off of the current HEAD in each project.
--sync=<bool> Take extra steps to ensure the branch you check out is up to date with origin,
either by pushing or pulling the remote tracking branch.
[default: .grapeconfig.post-checkout.syncWithOrigin]
--updateView If your submodules / nested projects change, change your workspace to match the changes.
Warning - setting this may cause you to lose unpushed work in nested subprojects.
--noUpdateView If your submodules / nested projects change, do not change your workspace to match the changes.
Arguments:
<branch> The name of the branch to checkout.
grape push pushes your current branch to origin for your outer level repo and all submodules.
it uses 'git push -u origin HEAD' for the git command.
Usage: grape-push [--noRecurse]
Options:
--noRecurse Don't perform pushes in submodules.
grape pull pulls any updates to your current branch into for your outer level repo and all subprojects.
Since a pull is really a remote merge, this is the same as grape mr <currentBranch>.
Usage: grape-pull [--continue] [--noRecurse]
Options:
--continue Finish a pull that failed due to merge conflicts.
--noRecurse Simply do a git pull origin <currentBranch> in the current directory.
Usage: grape-commit [-m <message>] [-a | <filetree>]
Options:
-m <message> The commit message.
-a Commit modified files that have not been staged.
Arguments:
<filetree> The relative path of files to include in this commit.
grape publish
Merges/Squash-merges/Rebases the current topic branch <type>/<username>/<descr> into the public <branch>,
where <public> is read from one of the <type>:<public> pairs found in .grapeconfig.flow.topicPrefixMappings,
.grapeconfig.flow.topicDestinationMappings, and/or .grapeconfig.workspace.submoduleTopicPrefixMappings. The
branch-dependent publish policy (merge vs. squash merge. vs rebase, etc) is decided using
grapeconfig.flow.publishPolicy for the top-level repo and the publish policy for
submodules is decided using grapeconfig.workspace.submodulePublishPolicy.
Usage: grape-publish [--squash [--cascade=<branch>... ] | --merge | --rebase]
[-m <msg>]
[--recurse | --noRecurse]
[--public=<public> [--submodulePublic=<submodulePublic>]]
[--topic=<branch>]
[--noverify]
[--nopush]
[--pushSubtrees | --noPushSubtrees]
[--forcePushSubtree=<subtreeName>]...
[--startAt=<startStep>] [--stopAt=<stopStep>]
[--buildCmds=<buildStr>] [--buildDir=<path>]
[--testCmds=<testStr>] [--testDir=<path>]
[--prepublishCmds=<cmds>] [--prepublishDir=<path>]
[--postpublishCmds=<cmds>] [--postpublishDir=<path>]
[--noUpdateLog | [--updateLog=<file> --skipFirstLines=<int> --entryHeader=<string>]]
[--tickVersion=<bool> [-T <arg>]...]
[--tickOnCascade=<slot> ]
[--user=<BitbucketUserName>]
[--bitbucketURL=<httpsURL>]
[--verifySSL=<bool>]
[--project=<BitbucketProjectKey>]
[--repo=<BitbucketRepoName>]
[-R <arg>]...
[--noReview]
[--useBitbucket=<bool>]
[--deleteTopic=<bool>]
[--emailNotification=<bool> [--emailHeader=<str> --emailFooter=<str>
--emailSubject=<str> --emailSendTo=<addr> --emailServer=<smtpserver> --emailMaxFiles=<int>]]
[<CommitMessageFile>]
[--remoteMerge]
grape-publish --continue
grape-publish --abort
grape-publish --printSteps
grape-publish --quick -m <msg> [--user=<BitbucketUserName>] [--public=<public>] [--noReview] [--remoteMerge]
Options:
--squash Squash merges the topic into the public, then performs a commit if the merge goes clean.
--cascade=<branch> For squash merges, can choose to cascade back to <branch> after the merge is
completed. Define multiple times to setup a chain of cascades. Overrides outer repo and
nestedSubproject cascades defined in .grapeconfig publish policies. Does not override
submodule publish policies.
--merge Perform a normal merge.
-m <msg> The commit message to use for a successful merge / squash merge. Ignored if used with
--rebase.
--rebase Rebases the topic branch to the public, then fast forwards the public to the tip of the
topic.
--recurse Perform the publish action in submodules.
Defaults to True if .grapeconfig.workspace.manageSubmodules is True.
--noRecurse Do not perform the publish action in submodules.
Defaults to True if .grapeconfig.workspace.manageSubmodules is False.
--topic=<branch> The branch to publish. Defaults to the current branch.
--noverify Set to skip interactive verification of publish commands.
--nopush Set to skip the push of commits generated during the publish procedure.
--pushSubtrees Push subtrees to their respective remotes (.grapeconfig.subtree-<name>.remote) appropriate
public branches (.grapeconfig.subtree-<name>.topicPrefixMappings)
Set by default if .grapeconfig.subtrees.pushOnPublish is True.
--noPushSubtrees Don't perform a git subtree push.
--startAt=<startStep> The publish step to start at. One of "testForCleanWorkspace1", "md1",
"ensureModifiedSubmodulesAreActive", "verifyPublishActions", "ensureReview",
"verifyCompletedReview", "markInProgress", "md2", "tickVersion", "updateLog",
"build", "test", "testForCleanWorkspace2", "prePublish", "publish", "postPublish",
"tagVersion", "performCascades", "markAsDone", "notify", or "deleteTopic".
--stopAt=<stopStep> The publish step to stop at. Valid values are the same as for --startAt. Publish will
perform all steps from <startStep> (inclusive) to <stopStep> (exclusive).
--continue Resume a previous call to grape publish that encountered a failure at one of the publish
steps.
--abort Abort a previously failed call to grape publish.
--buildCmds=<buildStr> The comma-delimited list of build commands to execute.
[default: .grapeconfig.publish.buildCmds]
--buildDir=<path> The directory (relative to the workspace root directory) to execute the build steps in.
[default: .grapeconfig.publish.buildDir]
--testCmds=<testStr> The comma-delimited list of test commands to execute.
[default: .grapeconfig.publish.testCmds]
--testDir=<path> The directory (relative to the workspace root directory) to execute the test steps in.
[default: .grapeconfig.publish.testDir]
--prepublishCmds=<str> The comma-delimited list of commands to execute just before the publish step.
[default: .grapeconfig.publish.prepublishCmds]
--prepublishDir=<str> The directory (relative to the workspace root directory) to execute the pre-publish cmds in.
[default: .grapeconfig.publish.prepublishDir]
--postpublishCmds=<str> The comma-delimited list of commands to execute just after the publish step.
[default: .grapeconfig.publish.postpublishCmds]
--postpublishDir=<str> The directory (relative to the workspace root directory) to execute the post-publish
cmds in.
[default: .grapeconfig.publish.postpublishDir]
--deleteTopic=<bool> Offer to delete the topic branch when done. [default: .grapeconfig.publish.deleteTopic]
--noUpdateLog Set to skip the updateLog step.
--updateLog=<file> The log file to update with the commit message for this branch.
[default: .grapeconfig.publish.updateLog]
--skipFirstLines=<int> The number of lines to skip in the updateLog file before inserting the commit message.
[default: .grapeconfig.publish.logSkipFirstLines]
--entryHeader=<string> The format for the commit message header. The string literals <date>, <user>, and <version>
will be replaced by the date, the result of git config --get user.name, and the result of
git describe --abbrev=0 after the tickversion step, respectively.
[default: .grapeconfig.publish.logEntryHeader]
--tickVersion=<bool> Tick a version number as a part of this publish action.
[default: .grapeconfig.publish.tickVersion]
--tickOnCascade=<slot> Tick the <slot> version number when performing a cascade.
Default behavior governed by the flow.topicCascadeTick mapping.
-T <arg> An argument to pass to grape-version tick. Type grape version --help for available options
and defaults. -T can be used multiple times to pass multiple arguments.
--user=<user> Your Bitbucket username.
--bitbucketURL=<url> Your Bitbucket URL, e.g. https://rzlc.llnl.gov/bitbucket .
[default: .grapeconfig.project.stashURL]
--verifySSL=<bool> Set to False to ignore SSL certificate verification issues.
[default: .grapeconfig.project.verifySSL]
--project=<project> Your Bitbucket Project. See grape-review for more details.
[default: .grapeconfig.project.name]
--repo=<repo> Your Bitbucket repo. See grape-review for more details.
[default: .grapeconfig.repo.name]
-R <arg> Argument(s) to pass to grape-review, in addition to --title="**IN PROGRESS**:" --prepend.
Type grape review --help for valid options.
--noReview Don't perform any actions that interact with pull requests. Overrides --useBitbucket.
--useBitbucket=<bool> Whether or not to use pull requests. [default: .grapeconfig.publish.useStash]
--public=<public> The branch to publish to. Defaults to the mapping for the current topic branch as described
by .grapeconfig.flow.topicDestinationMappings. .grapeconfig.flow.topicPrefixMappings is used
if no option for .grapeconfig.flow.topicDestinationMappings exists.
--submodulePublic=<b> The branch to publish to in submodules. Defaults to the mapping for the current topic branch
as described by .grapeconfig.workspace.submoduleTopicPrefixMappings.
--emailNotification=<b> Set to true to send a notification email after you've published. The email will consist of
a header <header> and a message, generally the contents of <CommitMessageFile> and/or
the Pull Request description, followed by a footer <footer>. The email is sent to <addr>,
and will be CC'd to the user.
For the email subject, header and footer, the string literals
'<user>', '<date>', '<version>', and '<public>' with the following:
<user>: the result of git config --get user.name
<date>: the current timestamp.
<version>: The version of the project, so long as grape is managing your versioning.
<public>: The branch to publish to.
[default: .grapeconfig.publish.emailNotification]
--emailHeader=<header> The email header. See above.
[default: .grapeconfig.publish.emailHeader]
--emailFooter=<footer> The email footer. See above.
[default: .grapeconfig.publish.emailFooter]
--emailSubject=<sbj> The email subject. See above.
[default: .grapeconfig.publish.emailSubject]
--emailSendTo=<addr> The comma-delimited list of receivers of the email.
[default: .grapeconfig.publish.emailSendTo]
--emailServer=<server> The smtp email server address.
[default: .grapeconfig.publish.emailServer]
--emailMaxFiles=<int> Maximum number of modified files (per subproject) to show in email.
[default: .grapeconfig.publish.emailMaxFiles]
--quick Perform the following steps only: md1, ensureModifiedSubmodulesAreActive, ensureReview,
markInProgress, md2, publish, markAsDone, deleteTopic, done]
--remoteMerge Perform the merge using the Bitbucket REST API.
Optional Arguments:
<CommitMessageFile> A file with an update message for this publish command. The pull request associated with
this branch will be updated to contain this message. If you don't specify a filename, grape
will give you an opportunity to use contents of the pull request description are intended for the update
message. Both the commit message for the merge and an update log will contain this message.
Additionally, if email notification is configured, the contents of the email will have
this message.
grape-clone
Clones a git repo and configures it for use with git.
Usage: grape-clone <url> <path> [--recursive] [--allNested]
Arguments:
<url> The URL of the remote repository
<path> The directory where you want to clone the repo to.
Options:
--recursive Recursively clone submodules.
--allNested Get all nested subprojects.
Configures the current repo to be optimized for GRAPE on LC
Usage: grape-config [--uv [--uvArg=<arg>]... | --nouv]
[--nocredcache | --credcache] [--p4merge]
[--nop4merge] [--p4diff] [--nop4diff] [--git-p4]
Options:
--uv walks you through setting up a sparse checkout for this repo. (interactive)
--nouv skips custom-view questions
--credcache enables https 12 hr credential cacheing.
--nocredcache disables https 12 hr credential cacheing (this option recommended for Windows users)
--p4merge will set up p4merge as your merge tool.
--nop4merge will skip p4merge questions.
--p4diff will set up p4merge as your diff tool.
--nop4diff will skip p4diff questions.
--git-p4 will configure your repo for use with git-p4 (deprecated)
grape writeConfig: Writes the current configuration to a file, using any configuration set
by ~/.grapeconfig or your <REPO_BASE>/.grapeconfig.
Usage:
grape-writeConfig <file> [--gitflow]
Executes a command in the top level project, each submodule, and each nested subproject in this workspace.
Usage: grape-foreach [--quiet] [--noTopLevel] [--noSubprojects] [--noSubmodules] [--currentCWD] <cmd>
Options:
--quiet Quiets git's printout of "Entering submodule..."
--noTopLevel Does not call <cmd> in the workspace directory.
--noSubprojects Does not call <cmd> in any grape nested subprojects.
--noSubmodules Does not call <cmd> in any git submodules.
--currentCWD grape foreach normally starts work from the workspace top level directory. This flag
starts work from the current working directory.
Arguments:
<cmd> The cmd to execute.
grape m
merge a local branch into your current branch
Usage: grape-m [<branch>] [--am | --as | --at | --aT | --ay | --aY | --askAll] [--continue] [--noRecurse] [--noUpdate] [--squash]
Options:
--am Use git's default merge.
--as Do a safe merge - force git to issue conflicts for files that
are touched by both branches.
--at Git accept their changes in any file touched by both branches (the branch you're merging from)
--aT Git accept their changes in the event of a conflict (the branch you're merging from)
--ay Git will accept your changes in any file touched by both branches (the branch you're currently on)
--aY Git will accept your changes in the event of a conflict (the branch you're currently on)
--askAll Ask to determine the merge strategy before merging each subproject.
--noRecurse Perform the merge in the current repository only. Otherwise, grape md --public=<branch>
will be called to handle submodule and nested project merges.
--continue Resume your previous merge after resolving conflicts.
--noUpdate Don't perform an update of your local version of <branch> from the remote before attempting
the merge.
--squash Perform squash merges.
Arguments:
<branch> The branch you want to merge in.
grape md (Merge Down)
merge changes from a public branch into your current topic branch
If executed on a public branch, performs a pull --rebase to update your local public branch.
Usage: grape-md [--public=<branch>] [--subpublic=<branch>]
[--am | --as | --at | --aT | --ay | --aY | --askAll]
[--continue]
[--recurse | --noRecurse]
[--noUpdate]
[--squash]
Options:
--public=<branch> Overrides the public branch to merge from.
Default behavior is to merge according to
.grapeconfig.flow.topicPrefixMappings.
--subpublic=<branch> Overrides the submodules' public branch to merge from. Default behavior is to merge
according to .grapeconfig.flow.submoduleTopicPrefixMappings.
--am Perform the merge using git's default strategy.
--as Perform the merge issuing conflicts on any file modified by both branches.
--at Perform the merge using the public branch's version for any file modified by both branches.
--aT Perform the merge resolving conficts using the public branch's version.
--ay Perform the merge using the your topic branch's version for any file modified by both branches.
--aY Perform the merge resolving conflicts using your topic branch's version.
--askAll Ask to determine the merge strategy before merging each subproject.
--recurse Perform merges in submodules first, then merge in the outer level keeping the
results of submodule merges.
--noRecurse Do not perform merges in submodules, just attempt to merge the gitlinks.
--continue Resume the most recent call to grape md that issued conflicts in this workspace.
--noUpdate Do not update local versions of the public branch before attempting merges.
--squash Perform squash merges.
grape mr (merge remote branch). If the remote branch is different from your current branch, this will update
or add a local version of that branch, then merge it into your current branch. If you perform a grape mr on the
current branch or if the remote branch can not be fastforward merged into your local version of that branch,
then this will do a merge assuming the remote branch has a different line of development than
your local branch. (Ideal for developers working on shared branches.)
Usage: grape-mr [<branch>] [--am | --as | --at | --aT | --ay | --aY | --askAll] [--continue] [--noRecurse] [--noUpdate] [--squash]
Options:
--am Perform the merge using git's default strategy.
--as Perform the merge issuing conflicts on any file modified by both branches.
--at Perform the merge using the remote branch's version for any file modified by both branches.
--aT Perform the merge resolving conficts using the remote branch's version.
--ay Perform the merge resolving conflicts using your topic branch's version.
--aY Perform the merge using your topic branch's version for any file modified by both branches.
--askAll Ask to determine the merge strategy before merging each subproject.
--noRecurse Perform the merge in the current repository only. Otherwise, this will call
grape md --public=<branch> to handle submodule and nested project merges.
--continue Resume your previous merge after resolving conflicts.
--squash Perform squash merges.
Arguments:
<branch> The name of the remote branch to merge in (without remote/origin or origin/ prefix)
Deletes a topic branch both locally and on origin for all projects in this workspace.
Usage: grape-db [-D] [
Options:
-D Forces the deletion of unmerged branches. If you are on the branch you
are trying to delete, this will detach you from the branch and then
delete it, issuing a warning that you are in a detached state.
--verify Verifies the delete before performing it.
Arguments:
<branch> The branch to delete. Will ask for branch name if not included.
grape cv: create a new custom view
Usage: grape-cv [--source=<repo>] [--dest=<name>] [--destPath=<path>] [[--noSparse] | [-- <uvargs>...]]
Options:
--source=<repo> Path to original clone.
--dest=<name> Name of new workspace.
--destPath=<path> Path (must exist) to place new workspace in.
Full path to workspace will be <path>/<name>
--noSparse Skips grape uv, does a vanilla checkout instead.
Arguments:
<uvargs> Arguments to pass to grape uv. Note that if you are using the -f
option, you should use an absolute path.
grape review
Usage: grape-review [--update | --add]
[--title=<title>]
[--descr=<file> | -m <description>]
[--user=<userName> ]
[--reviewers=<userNames>]
[--source=<topicBranch>]
[--target=<publicBranch>]
[--state=<openMergedDeclined>]
[--bitbucketURL=<url>]
[--verifySSL=<bool>]
[--project=<prj>]
[--repo=<repo>]
[--recurse]
[--norecurse]
[--test]
[--prepend | --append]
[--subprojectsOnly]
Options:
--update Update an existing pull request with a new description, set of reviewers, etc.
This is the default behavior if a pull request already exists for <topicBranch>
targeting <publicBranch>. If --update is set, and an open pull request doesn't
exist, an error will be generated.
--add Add a new pull request. Default behavior if a pull request doesn't exist for
<topicBranch> targeting <publicBranch>. If a pull request already exists and --add
is set, an error will be generated.
--title=<title> The pull request`s title.
--descr=<file> A file containing the detailed description of work done on <topicBranch>.
-m <description> The pull request description.
--user=<userName> Your Bitbucket user name.
--reviewers=<userNames> A space-separate list of reviewers for <topicBranch>
--source=<topicBranch> The branch to review. Defaults to current branch.
--target=<publicBranch> The branch to publish <topicBranch> to.
Defaults to .grapeconfig.topicPrefixMappings[topicBranchPrefix].
--state=<state> The state of the pull request to update. Valid values are open, merged, and
declined.
[default: open]
--bitbucketURL=<url> The bitbucket url, e.g. https://rzlc.llnl.gov/bitbucket.
[default: .grapeconfig.project.stashURL]
--verifySSL=<bool> Set to False to ignore SSL certificate verification issues.
[default: .grapeconfig.project.verifySSL]
--project=<prj> The project key part of the bitbucket url, e.g. the "GRP" in
https://rzlc.llnl.gov/bitbucket/projects/GRP/repos/grape/browse.
[default: .grapeconfig.project.name]
--repo=<repo> The repo name part of the bitbucket url, e.g. the "grape" in
https://rzlc.llnl.gov/bitbucket/projects/GRP/repos/grape/browse.
[default: .grapeconfig.repo.name]
--recurse If set, adds a pull request for each modified submodule and nested subproject.
The pull request for the outer level repo will have a description with links to the
submodules' pull requests. On by default if grapeConfig.workspace.manageSubmodules
is set to true.
--norecurse Disables adding pull requests to submodules and subprojects.
--test Uses a dummy version of stashy that requires no communication to an actual Bitbucket
server.
--prepend For reviewers, title, and description updates, prepend <userNames>, <title>, and
<description> to the existing title / description instead of replacing it.
--append For reviewers, title, and description updates, append <userNames>, <title>, and
<description> to the existing reviewers, title, or description instead of replacing it.
--subprojectsOnly As a work around to when you've only touched a subproject, this will prevent errors
arising
grape test
Runs grape's unit tests.
Usage: grape-test [--debug] [<suite>]...
Arguments:
<suite> The name of the suite to test. The default is all.
Enter listSuites as the suite name to list available suites.
grape up
Updates the current branch and any public branches.
Usage: grape-up [--public=<branch> ]
[--recurse | --noRecurse [--recurseSubprojects]]
[--wd=<working dir>]
Options:
--public=<branch> The public branches to update in addition to the current one,
e.g. --public="master develop"
[default: .grapeconfig.flow.publicBranches ]
--recurse Update branches in submodules and nested subprojects.
--noRecurse Do not update branches in submodules and nested subprojects.
--wd=<working dir> Working directory which should be updated.
Top level workspace will be updated if this is unspecified.
--recurseSubprojects Recurse in nested subprojects even if you're not recursing in submodules.
grape updateSubproject
Updates an existing subproject from its host repository.
Usage: grape-updateSubproject subtree --name=<name> --branch=<committish>
Options:
--name=<name> The name of the subproject. Must match a [subtree-<name>] section in .grapeconfig
that has prefix and remote options defined.
--branch=<b> The branch in the subtree's host repository whose state you want in your
repository.
grape installHooks
Installs callbacks to grape in .git/hooks, allowing grape-configurable hooks to be used
in this repo.
Usage: grape-installHooks [--noRecurse] [--toInstall=<hook>]...
Options:
--noRecurse If set, do not recurse into submodules and nested subprojects.
--toInstall=<hook> the list of hook-types to install
[default: pre-commit pre-push pre-rebase post-commit post-rebase post-merge post-checkout]
grape runHook
Usage: grape-runHook
grape-runHook pre-commit [--noExit]
grape-runHook pre-push <dest> <url> [--noExit]
grape-runHook pre-rebase <basebranch> [<rebasebranch>] [--noExit]
grape-runHook post-commit [--autopush=<bool>] [--cascade=<pairs>] [--noExit]
grape-runHook post-rebase [--rebaseSubmodule=<bool>] [--noExit]
grape-runHook post-merge <wasSquashed> [--mergeSubmodule=<bool>] [--noExit]
grape-runHook post-checkout <prevHEAD> <newHEAD> <isBranchCheckout> [--checkoutSubmodule=<bool>] [--noExit]
Options:
--autopush=<bool> autopushes commits to origin
[default: .grapeconfig.post-commit.autopush]
--cascade=<pairs> performs a post commit cascade
[default: .grapeconfig.post-commit.cascade]
--rebaseSubmodule=<bool> [default: .grapeconfig.post-rebase.submoduleUpdate]
--mergeSubmodule=<bool> [default: .grapeconfig.post-merge.submoduleUpdate]
--checkoutSubmodule=<bool> [default: .grapeconfig.post-checkout.submoduleUpdate
--noExit Normally runhook returns by calling exit(0). With this flag, returns by returning
True.
Arguments:
<dest> (pre-push only) The destination repo.
<url> (pre-push only) The destination's URL.
<basebranch> (pre-rebase only) The upstream commit this branch was forked from.
<rebasebranch> (pre-rebase only) The branch being rebased (empty when rebasing current branch)
<wasSquashed> (post-merge only) Status flag indicating whether the merge was a squash merge.
grape uv - Updates your active submodules and ensures you are on a consistent branch throughout your project.
Usage: grape-uv [-f ] [--checkSubprojects] [-b] [--skipSubmodules] [--allSubmodules]
[--skipNestedSubprojects] [--allNestedSubprojects] [--sync=<bool>]
[--add=<addedSubmoduleOrSubproject>...] [--rm=<removedSubmoduleOrSubproject>...]
Options:
-f Force removal of subprojects currently in your view that are taken out of the view as a
result to this call to uv.
--checkSubprojects Checks for branch model consistency across your submodules and subprojects, but does
not go through the 'which submodules do you want' script.
-b Automatically creates subproject branches that should be there according to your branching
model.
--allSubmodules Automatically add all submodules to your workspace.
--allNestedSubprojects Automatically add all nested subprojects to your workspace.
--sync=<bool> Take extra steps to ensure the branch you're on is up to date with origin,
either by pushing or pulling the remote tracking branch.
This will also checkout the public branch in a headless state prior to offering to create
a new branch (in repositories where the current branch does not exist).
[default: .grapeconfig.post-checkout.syncWithOrigin]
--add=<project> Submodule or subproject to add to the workspace. Can be defined multiple times.
--remove=<project> Submodule or subproject to remove from the workspace. Can be defined multiple times.
grape version
This command is used for projects that wish to have their version numbers managed by grape.
The read subcommand is a no-op - it is used internally by other grape/vine modules.
Usage: grape-version init <version> --file=<path> [--matchTo=<str>] [--prefix=<verPrefix>] [-suffix=<verSuffix>]
[--tag | --notag | --updateTag=<bool>]
grape-version tick [--major | --minor | --slot=<int>]
[--tag | --notag | --updateTag=<bool>]
[--matchTo=<matchTo>]
[--prefix=<prefix>] [--suffix=<sufix>] [--tagPrefix=<prefix>] [--tagSuffix=<sufix>][--file=<path>]
[--nocommit]
[--notick]
[--tagNested]
[--public=<branch>]
grape-version read [--prefix=<prefix>] [--suffix=<suffix>] [--file=<file>]
Arguments:
<version> Used by grape version init, this is the initial version that grape will start counting from.
Options:
--file=<file> The file to store the version number. When used with init, this is mandatory, and
grape will update your .grapeconfig file for future version number lookups.
[default: .grapeconfig.versioning.file]
--matchTo=<matchTo> The regex to match to before reaching the version descriptor. Grape will look for the string
literals '<prefix>' and '<suffix>' in your regex and substitute your values for <prefix>
and <suffix> in their place. Default can be overridden using
.grapeconfig.versioning.branchVersionRegexMappings.
Note that, if defining matchTo in .grapeconfig.versioning.branchVersionRegexMappings, you
should ensure you use \s instead of ' ' as part of your regex, as the list of mappings uses
whitespace as a delimiter.
Currently, grape expects there to be 4 groups in your regex, with the version number in
group 3.
[default: (VERSION_ID\s*=\s*)(<prefix>)(\S+)(<suffix>)]
--matchGroup=<int> The regex group to pick the version number from. [default:3]
--prefix=<prefix> The version number prefix for version string to match in <file>, such as the 'v' in v1.2.3.
[default: .grapeconfig.versioning.prefix]
--suffix=<suffix> The version number suffix for grape-version to match in <file>, such as the 'm' in v1.2.3.m
[default: ]
--major Tick the Major (1st) version number.
--minor Tick the Minor (2nd) version number.
--slot=<int> Tick the <int>'th version number. 1 = Major, 2 = Minor, 3 = third, etc. If <int> is bigger
than the current max number of digits, the version number will be extended to have <int>
digits. Default value comes from .grapeconfig.versioning.branchSlotMappings.
--public=<branch> The public branch to use for determine the slot to tick. Default based on
.grapeconfig.flow.topicprefixmappings. Grape publish uses this option to ensure the version
ticking is consistent with the --public option passed to grape publish.
--updateTag=<bool> If true, update the version git annotated tag. [default: .grapeconfig.versioning.updateTag]
--tag Forces updateTag to be True.
--notag Forces updateTag to be False.
--tagPrefix=<str> The prefix for the git version tags. [default: v]
--tagSuffix=<str> The suffix for the git version tags. Default value comes from
.grapeconfig.versioning.branchTagSuffixMappings.
--nocommit Do not create a new commit, just modify <file>. This implies --updateTag=False.
--notick Do not tick the version in <file>. Useful with --tag to tag HEAD as being the current
version in <file>.
--tagNested Tag any active nested subprojects.
grape w(alkthrough)
Usage: grape-w [--difftool=<tool>] [--height=<height>] [--width=<width>] [--showUnchanged] [--noFetch]
[--mergeDiff | --rawDiff ]
[--noInactive] [--noTopLevel] [--noSubmodules] [--noSubtrees] [--noNestedSubprojects]
[<b1>] [--staged | --workspace | <b2>]
Options:
--difftool=<tool> Command to use for diff.
Valid choices are: kdiff3, kompare, tkdiff,
meld, xxdiff, emerge, gvimdiff,
ecmerge, diffuse, opendiff, p4merge, and araxis.
If unspecified, default git difftool will be used.
--height=<height> Height of window in pixels.
[default: .grapeconfig.walkthrough.height]
--width=<width> Width of window in pixels.
[default: .grapeconfig.walkthrough.width]
--staged Compare staged changes with branch <b1>.
--workspace Compare workspace files with branch <b1>.
--mergeDiff Perform diff of branches from common ancestor (diff <b1>...<b2>) (default).
--rawDiff Perform raw diff of branch files (diff <b1> <b2>).
--showUnchanged Show unchanged subprojects.
--noFetch Do not fetch.
--noInactive Do not show inactive subprojects.
--noTopLevel Do not show outer level project.
--noSubmodules Do not show submodules.
--noSubtrees Do not show nested subtrees.
--noNestedSubprojects Do not show nested subprojects.
<b1> The first branch to compare.
Defaults to the current branch of workspace.
<b2> The second branch to compare.
Defaults to the public branch for <b1>.
grape q
Quits grape.
Usage: grape-q
grape <newtopicbranch>
Creates a new topic branch <type>/<username>/<descr> off of a public <branch>, where <type> is read from
one of the <type>:<branch> pairs found in .grapeconfig.flow.topicPrefixMappings.
Usage: grape-<type> [--start=<branch>] [--user=<username>] [--noverify] [--recurse | --noRecurse] [<descr>]
Options:
--user=<username> The user developing this branch. Asks by default.
--start=<branch> The start point for this branch. Default comes from .grapeconfig.flow.topicPrefixMappings.
--noverify By default, grape will ask the user to verify the name and start point of the branch.
This disables the verification.
--recurse Create the branch in submodules.
[default: .grapeconfig.workspace.manageSubmodules]
--noRecurse Don't create the branch in submodules.
Optional Arguments:
<descr> Single word description of work being done on this branch. Asks by default.
grape <newtopicbranch>
Creates a new topic branch <type>/<username>/<descr> off of a public <branch>, where <type> is read from
one of the <type>:<branch> pairs found in .grapeconfig.flow.topicPrefixMappings.
Usage: grape-<type> [--start=<branch>] [--user=<username>] [--noverify] [--recurse | --noRecurse] [<descr>]
Options:
--user=<username> The user developing this branch. Asks by default.
--start=<branch> The start point for this branch. Default comes from .grapeconfig.flow.topicPrefixMappings.
--noverify By default, grape will ask the user to verify the name and start point of the branch.
This disables the verification.
--recurse Create the branch in submodules.
[default: .grapeconfig.workspace.manageSubmodules]
--noRecurse Don't create the branch in submodules.
Optional Arguments:
<descr> Single word description of work being done on this branch. Asks by default.
grape <newtopicbranch>
Creates a new topic branch <type>/<username>/<descr> off of a public <branch>, where <type> is read from
one of the <type>:<branch> pairs found in .grapeconfig.flow.topicPrefixMappings.
Usage: grape-<type> [--start=<branch>] [--user=<username>] [--noverify] [--recurse | --noRecurse] [<descr>]
Options:
--user=<username> The user developing this branch. Asks by default.
--start=<branch> The start point for this branch. Default comes from .grapeconfig.flow.topicPrefixMappings.
--noverify By default, grape will ask the user to verify the name and start point of the branch.
This disables the verification.
--recurse Create the branch in submodules.
[default: .grapeconfig.workspace.manageSubmodules]
--noRecurse Don't create the branch in submodules.
Optional Arguments:
<descr> Single word description of work being done on this branch. Asks by default.
grape <newtopicbranch>
Creates a new topic branch <type>/<username>/<descr> off of a public <branch>, where <type> is read from
one of the <type>:<branch> pairs found in .grapeconfig.flow.topicPrefixMappings.
Usage: grape-<type> [--start=<branch>] [--user=<username>] [--noverify] [--recurse | --noRecurse] [<descr>]
Options:
--user=<username> The user developing this branch. Asks by default.
--start=<branch> The start point for this branch. Default comes from .grapeconfig.flow.topicPrefixMappings.
--noverify By default, grape will ask the user to verify the name and start point of the branch.
This disables the verification.
--recurse Create the branch in submodules.
[default: .grapeconfig.workspace.manageSubmodules]
--noRecurse Don't create the branch in submodules.
Optional Arguments:
<descr> Single word description of work being done on this branch. Asks by default.
grape <newtopicbranch>
Creates a new topic branch <type>/<username>/<descr> off of a public <branch>, where <type> is read from
one of the <type>:<branch> pairs found in .grapeconfig.flow.topicPrefixMappings.
Usage: grape-<type> [--start=<branch>] [--user=<username>] [--noverify] [--recurse | --noRecurse] [<descr>]
Options:
--user=<username> The user developing this branch. Asks by default.
--start=<branch> The start point for this branch. Default comes from .grapeconfig.flow.topicPrefixMappings.
--noverify By default, grape will ask the user to verify the name and start point of the branch.
This disables the verification.
--recurse Create the branch in submodules.
[default: .grapeconfig.workspace.manageSubmodules]
--noRecurse Don't create the branch in submodules.
Optional Arguments:
<descr> Single word description of work being done on this branch. Asks by default.