Git cheatsheet - tips and tricks

Introduction

If you feel you’ve outgrown the cheat sheet, below are a few extra tips that might appeal to developers who enjoy taking a look behind the scenes.

• Speed up cloning and fetching
• A note about $keyword$ expansion
• Making a change to a submission comprising several commits
• Skipping the version number increment step
• Getting the time stamps right

Speed up cloning and fetching

It is possible to run the submodule cloning step in parallel which speeds things up by up to 500%.

git clone https://gitlab.riscosopen.org/Products/IOMDHAL.git
cd IOMDHAL
git submodule update --init --remote --no-fetch --jobs 8

or

git clone --recurse-submodules --remote-submodules --jobs 8 https://gitlab.riscosopen.org/Products/IOMDHAL.git

Experimentally, running more than 8 jobs in parallel results in little extra gain.

A note about $keyword$ expansion

Under CVS certain keywords surrounded by dollar signs would automatically be expanded when a file was checked out, this would allow things like the $Author$ to be included. While rarely useful, this expansion doesn’t occur with Git so we have discontinued their use. You may still see the odd $keyword$ appearing files, these have been harmlessly left unexpanded to keep things like line number references intact.

Making a change to a submission

This assumes you have already pushed your development branch to your fork project at least once, and wish to change its contents (for example, due to comments received during review of your merge request).

If your merge request is made up of multiple commits, or if somebody else’s submission has been merged since you opened your merge request, a slightly more complex procedure is required, as follows.

git rebase -i master

In the rare case where your development branch didn’t branch off from the master branch (which is what was called the trunk in CVS), you would substitute a different branch name in place of master.

This command opens a list of commits in an editor and allows to specify which commits you are going to edit. It then rewinds your commits and reapplies each one it turn; if you said you wanted to edit one, then it will wait for you to make changes. Once you have made the changes, stage them using

git add -i

and resume the rebase operation using

git rebase --continue

and lastly send the edited set of commits for consideration with

git push --force

GitLab will automatically update any merge request with your new commits.

Skipping the version number increment step

Normally when a merge request is accepted the version number of that component is incremented by 0.01, the date (that appears in the application’s Info box or module help string) is set to today’s date, and a tag is applied derived from the component name and version.
In addition to this we support some special markers to alter this default behaviour, though note that these are not expected in normal use and may slow down acceptance of a merge request while their applicability is considered.

No change

For changes that don’t affect the binary a user receives, such as correcting spelling mistakes in comments, you can add the special marker

!NoChange

on a line of its own in the topmost commit for the submission. During merging no change is made to the version number or date, and no new tag is applied.

No tag

For clerical changes that alter the binary but not in a material way, such as adding embedded function signatures, you can add the special marker

!NoTag

on a line of its own in the topmost commit for the submission. During merging the version number is unchanged, the date is updated, and no new tag is applied.

Specific version number

Let’s say a significant new feature was added so you wish to go from version 3.45 to 4.00. To do this, edit the VersionNum file to 3.99 such that when merged the usual machinery will increment it by 0.01 to the desired final number. In general artificial version number inflation is not encouraged.

Specific tag

This option does not work when a standard VersionNum file exists; it can only be used when the component is non-standard by either not having a VersionNum file at all or its contents are not maintained by srccommit. This applies to very few components and its use is only documented here for completeness.

!Tag(my_tag_123)

on a line of its own in the topmost commit for the submission. During merging the tag my_tag_123 is applied and nothing else.

Getting the time stamps right

By default, Git will checkout files and give them today’s date. This may be inconvenient if the time stamps have significance, for example a backup utility that skips unchanged files, allowing the Filer’s newer option to skip older files, or building components that embed the time stamp in their resources.

A small python script git-mtime.py is provided to (recursively if required) re-stamp all checked out files with the date they were last committed.