This command merges all changes currently in the given branch to your current branch. This can produce a merging commit on your branch sticking the two branch together (so-called tree merge). However in case there are no changes in your branch that wouldn't be in the remote branch, no merge commit is done and commit pointer of your branch is just updated to the last commit on the remote branch (so-called fast-forward merge).

In case of conflicts being generated by the merge, you have to examine the tree (cg-merge will tell you which files contain commits; the commits are denoted by rcsmerge-like markers <<<<, ====, and >>>>) and then do cg-commit(1) yourself. cg-commit(1) will know that you are committing a merge and will record it properly.

Note that when you are merging remote branches, cg-merge(1) will use them in the state they are currently at in your repository. If you want to fetch the latest changes from the remote repository, use cg-fetch(1). If you want to fetch the changes and then merge them to your branch, use the command cg-update(1).

Also note that if you have local changes in your tree that you did not commit, cg-merge will always preserve them when fast-forwarding. When doing a tree merge, it will preserve them if they don't conflict with the merged changes, and report an error otherwise. In short, it should do the Right Thing (tm), never lose your local changes and never let them mix up with the merge.

-b BASE_COMMIT

Parameter specifies the base commit for the merge. Otherwise, the least common ancestor is automatically selected.

-c

Parameter specifies that you want to have tree merge never autocommitted, but want to review and commit it manually. This will basically make cg-merge always behave like there were conflicts during the merge.

-j

Join the current branch and BRANCH_NAME together. This makes sense when the branches have no common history, meaning they are actually not branches related at all as far as GIT is concerned. Merging such branches might be a user error and you well may be doing something you do not want; but equally likely, you may actually WANT to join the projects together, which is what this option does.

--squash

"Squash" merge - condense all the to-be-merged commits to a single merge commit. This means "throw away history of the branch I'm merging", essentially like in CVS or SVN, with the same problem - re-merging with that branch later will cause trouble. This is not recommended unless you actually really want to flatten the history of the merged branch, e.g. when merging topical branches to your mainline (you want to have the logical change you developed in a branch as a single "do it" commit instead of a sequence of "do it I", "fix it", "do it II", "fix it II", "fix it III" commits like you would get with a regular merge).

-v

Display more verbose output - most notably list all the files touched by the merged changes.

-h, --help

Print usage summary.

--long-help

Print user manual. The same as found in cg-merge(1).

.git/hooks/merge-pre BRANCH BASE CURHEAD MERGEDHEAD MERGETYPE

If the file exists and is executable it will be executed right before the merge itself happens. The merge is cancelled if the script returns non-zero exit code.

*

MERGETYPE is either "forward", "squash", or "tree".

.git/hooks/merge-post BRANCH BASE CURHEAD MERGEDHEAD MERGETYPE STATUS

If the file exists and is executable it will be executed after the merge is done.

*

MERGETYPE is either "forward", "squash", or "tree".

*

For forward, the STATUS is always "ok", while for "squash" and "tree" the STATUS can be "localchanges", "conflicts", "nocommit", or "ok".