GIT perspective

GIT perspective is a group of views and editors which is used to work with local and remote GIT repositories.

GIT perspective includes 6 views and 1 editor:

	GIT Repositories →	is used for managing local GIT repositories
	GIT Staging →	shows changes added to the working tree and is used for committing these changes to your GIT repositories
	GIT Reflog	shows the Git reflog for a selected repository
	GIT Tree Compare	shows the change state (added, deleted, changed, or unchanged) of projects and folders and allows browsing and viewing files in the compare editor
	Rebase Interactive	allows interactive rebase (i.e. quick editing of commits including their removing, amending, squashing, etc.)
	Package Explorer	allows navigating through your projects in a way similar to project explore in the 4gl perspective

Properties, History, and Synchronize views are opened automatically when you open the GIT perspective but they are only associated with GIT perspective and not belong to it.

Package Explorer view can be opened only in the GIT perspective. It opens in the bottom left corner of the GIT perspective, directly below the GIT repositories view:

The included views can be opened both in the GIT perspective and in other perspective (e.g. in 4gl perspective):

Here you can find out how to open and manipulate perspectives.

Here you can find out how to open and manipulate views.

Label decorations

Label decorations show the GIT-specific information about resources in the projects added to the version control.

They appear in all views that show model objects (like Package Explorer, Project Explorer, GIT Staging, Navigator, and Hierarchy View).

You can switch GIT label decorations on/off globally at

Window → Preferences → General → Appearance → Label Decorations

and modify them at Window→Preferences→Team→GIT→Label Decorations:

There are two types of label decorations, text decorations and icon decorations.

Text decorations

Text decorations appear on the left or right side of the text label:

In the example above, > on the left side of the project name - widgets - shows that it is a dirty resource, and [] on the right enclose the repository name and the name of the active branch.

Text decorations can be configured at Window→Preferences→Team→GIT→Label Decorations →Text Decorations:

By default, you get these text decorations:

Text decorations are specified by setting corresponding variables.

Files, folders, projects, and submodules can have the following variables - name, dirty, and staged. dirty and staged are flags: If they are true, the text specified after colon is displayed. In the example above,

• with widgets, dirty is true, and  > is displayed;
• with form_properties, and regular_expressions, dirty is false, and they do not get  > on the left of their name.

Projects and submodules can have (besides the basic three) the following additional variables - repository, branch, branch_status, short_message:

→ repository displays the name of the repository;

→ branch displays the name of the currently checked out branch;

If no branch is checked out, the decoration will show the shortened name of the commit (first seven characters followed by the ellipsis).

If tags and/or remote branches point to this commit, this information is shown according to a "best guess" heuristic: tags take precedence over remote branches, and newer tags precede over the later ones. If there are several remote branches or tags that have no modification date, then they are sorted alphabetically, and the last one is displayed;

→ branch_status shows the status of the local branch as compared to the remote-tracking branch that is set as upstream:

↑ N reads as "N commits to push" meaning that the local branch has N commits that were not yet added to the remote-tracking branch,

↓ M reads as "M commits to merge/rebase" meaning that the remote-tracking branch has M commits that are not on the local branch,

↑ N↓M means that the  local and the remote-tracking branch have diverged (both options are applied),

empty if both local and remote-tracking branches in the same state.

The status variable can have a leading space like this - { branch_status}. In this case, a space is added to the variable if  the status is not empty.

→ short_message shows the first line of the commit message of the HEAD commit.

In the example above,

• you get the repository name and the name of the active branch - [lycia_doc_examples develop] - for widgets and form_properties that are added to the GIT repository;
• you get nothing for regular_expressions that is disconnected from any repositories and exists only in your workspace.

In the example below, the repository's active branch is develop, and the local develop branch has one commit which is still absent from the remote tracking branch:

Here is how a project looks like if all the possible text decorations are added:

Default variables can be changed by pressing Add Variables... and checking the necessary checkbox (or all):

To delete a variable, just it in the corresponding line and press Delete on your keyboard.

Icon decorations

Icon decorations appear on the lower right corner of the icon displayed before the label of a file, a project, or a sub-module:

In the example above, a small orange battery-like decoration in the project icon shows that all files in it are added to the version control.

Icon decorations can be configured at Window → Preferences → Team → GIT → Label Decorations → Icon Decorations:

By default, you get these icon decorations:

tracked	resources are added to the version control and are known to the GIT repository
untracked	resources are not known to the GIT repository and will not be version-controlled until explicitly added
ignored	resources are ignored by the GIT team provider (appears then a file is added to the Ignore list or gets the derived flag)
dirty	(text and icon decorations combined) resources are changed, but these changes are absent from both the GIT index and GIT repositories
dirty (folder)	(text and icon decorations combined) least one file from the folder is dirty
staged	resource changes are added to the GIT index
partially-staged	(text and icon decorations combined) resource has both changes which are added to the GIT index and additional changes in the working tree that neither reached the GIT index nor have been committed to the repository (refer here for details)
added	resources have not yet been committed to the repository but have been freshly added to the GIT repository in order to be tracked in future
removed	resources are staged for removal from the GIT repository
conflict	(text and icon decorations combined) there is a conflict in/with the resource
assume-unchanged	resources have the assume unchanged flag which means that GIT stops checking the working tree files for possible modifications, so you need to manually tell GIT when you change the working tree file