The Index

The Index is an intermediate cache for preparing a commit. With SmartGit, you can make heavy use of the Index, or ignore its presence completely - it‘s all up to you.

The Stage command allows you to save a file‘s content from your working tree in the Index. If you stage a file that was previously version-controlled, but is now missing in the working tree, it will be marked for removal. Explicitly using the Remove command has the same effect, as you may be accustomed to from SVN. If you select a file that has Index changes, invoking Commit will give you the option to commit all staged changes.

If you have staged some file changes and later modified the working tree file again, you can use the Discard command to either revert the working tree file content to the staged changes stored in the Index, or to the file content stored in the repository (HEAD). The Changes view of the SmartGit project window can show the changes between the HEAD and the Index, between the HEAD and the working tree, or between the Index and the working tree state of the selected file. Individual change hunks can be staged and unstaged there.

When unstaging previously staged changes, the staged changes will be moved back to the working tree, if the latter hasn‘t been modified in the meantime, otherwise the staged changes will be lost. In either case, the Index will be reverted to the HEAD file content.

Important Git Commands

This chapter gives you an overview of important SmartGit commands.

Synchronizing with Remote Repositories

Synchronizing the states of local and remote repositories consists of pulling from and pushing to the remote repositories. SmartGit also has a Synchronize command that combines pulling and pushing.

Pull

The Pull command fetches commits from a remote repository, stores them in the remote branches, and optionally ‘integrates‘ (i.e. merges or rebases) them into the local branch.

Use Remote|Pull (or the corresponding toolbar button) to invoke the Pull command. This will open the Pull dialog, where you can specify what SmartGit will do after the commits have been fetched: Merge the local commits with the fetched commits or rebase the local commits onto the fetched commits. In the latter case, you can merge or rebase by hand, as explained in Merge and Rebase, respectively. These options are meaningless, if you select to Fetch Only.

The Pull dialog allows you to set your choice as default for the current branch. To change the default choice for new branches, go to Repository|Settings.

If a merge or rebase is performed after pulling, it may fail due to conflicting changes. In that case SmartGit will leave the repository in a merging or rebasing state so you can either resolve the conflicts and proceed, or abort the operation. See Merge and Rebase for details.

Pulling tags

By default, Git (and hence SmartGit) will only pull new tags, but don‘t update possibly changed tags from the remote repository. To have tags updated as well, you have to configure --tags as tagopt for your remote.

Push

The various Push commands allow you to push (i.e. send) your local commits toone or more remote repositories.SmartGit distinguishes between the following Push commands:

• Push Pushes all commits in one or more local branches to their matching remotebranches.More precisely, on the Push dialog you can choose between pushing the commits inthe current branch to its matching remote branch, and pushing the commits in alllocal branches with matching remote branches to said remote branches.A local branch `matches‘ a remote branch if the branch names match, e.g.`master‘ and `origin/master‘.With this Push command you can push to multiple repositories in a single invocation.SmartGit will detect automatically whether a forced push will be necessary.
• Push To Pushes all commits in the current branch either to its matching branch,or to a ref specified by name.With the Push To command you can only push to one remote repository at a time.If multiple repositories have been set up, the Push To dialog will allow you to selectthe remote repository to push to.Also, the Push To command always allows to do a forced push, what can be convenient.This is necessary when pushing to a secondary remote repository for whichforcing the push may be necessary while it is not when pushing to the primary remoterepository (i.e. the one which is considered by SmartGit‘s forced push detection).You can also invoke Push To on a remote to push (or synchronize) all branchesfrom the selected remote to another remote.
• Push Commits Pushes the selected range of commits from the Outgoingview, rather than all commits, in the current branch to its tracked remote branch.

If you try to push commits from a new local branch, you will be asked whetherto set up tracking for the newly created remote branch.In most cases it is recommended to set up tracking, as it will allow you to receivechanges from the remote repository and make use of Git‘s branch synchronization mechanism(see Branches).

The Push commands listed above can be invoked from several places in SmartGit‘sproject window:

• Menu and toolbar In the menu, you can invoke the various Pull commands withRemote|Push, Remote|Push Toand Remote|Push Commits.The first two may also be available as toolbar buttons, depending on your toolbarconfiguration.The third command is only enabled if the Outgoing view is focused.
• Repositories view You can invoke Push in the Repositories viewby selecting the open repository and choosing Push from thecontext menu.
• Branches view In the context menu of the Branches view, you can invokePush and Push To on local branches.Additionally, you can invoke Push on tags.
• Outgoing view To push a range of commits up to a certain commit, select thatcommit in the Outgoing view and invoke Push Commitsfrom the context menu.

Synchronize

With the Synchronize command, you can push local commits to a remote repositoryand pull commits from that repository at the same time.This simplifies the common workflow of separately invoking Pushand Pull to keep your repository synchronizedwith the remote repository.

If the Synchronize command is invoked and there are both local and remote commits,the invoked push operation fails.The pull operation on the other hand is performed even in case of failure, so thatthe commits from the remote repository are available in the tracked branch, readyto be merged or rebased.After the remote changes have been applied to the local branch, you may invoke theSynchronize command again.

In SmartGit‘s project window, the Synchronize command can be invoked as follows:

• from the menu via Remote|Synchronize,
• with the Synchronize toolbar button,
• and in the Repositories view via Synchronize in therepository‘s context menu.

Viewing the Project History

Log

SmartGit‘s Log displays the repository‘s history as a list of commits, sortedby increasing age, and with a graph on the left side to show the parent-child relationshipsbetween the commits.What is shown on the Log depends on what was selected when the Log command was invoked:

• To view the history of the entire repository (root Log), select the repositoryin the Repositories view before invoking the Log command.
• To view the history of a directory within the repository, select the directory inthe Repositories view before invoking the Log command.
• To view the history of a single file within the repository, select the file in theFiles view before invoking the Log command.If the file is not visible in the Files view, either adjust the file table‘sfilter settings (on its top right), or enter the name of the file in the search fieldabove the file table.

A root Log can be invoked from other places in SmartGit as well:

• Branches view In the Branches view (just project window), you can right-clickon a branch and select Log to open the Log for the selectedbranch.
• Outgoing view In the Outgoing view, you can right-click on a specificcommit and invoke Log to open the Log for the current branch,with the selected commit pre-selected in the Log.

Log Commands

In the Log Frame, many commands which are known from the Project Windoware available as well:

• most of them are available from the main menu bar
• the context menu on a commit provides certain commands
• certain items in the Graph view, like local refs or the HEAD-arrow canbe modified using drag-and-drop.

Links to issue trackers

If you have set up a so called Bugtraq Configuration, SmartGit will detectissue IDs in commit messages and display links to the issue tracker in this case.The Bugtraq configuration is stored either in the .gitbugtraq file inyour repository root (for all users of the repository) or in your repositories‘ .git/config(just for you).It consists of a named bugtraq section which basically defines a regularexpression to match issue IDs in your commit message and an URL template to openwhen clicking at such an issue link.

The logRegex must contain only one matching group ‘()‘ matching theissue ID.You can use additional non-matching groups ‘(?:)‘ for other parts of your regex (or‘(?i)‘ for case insensitive matching).For more details refer to the complete specification at https://github.com/mstrap/bugtraq.

Blame

SmartGit‘s Blame window displays the history information for a single file ina way that helps you to track down the commit in which a certain portion of codewas introduced into the repository.You can open the Blame window by selecting a file in the Files view in SmartGit‘sproject window and invoking Query|Blamefrom the program menu.The Blame window consists of a Document view and a History of current lineview.

Document view

The Document view is divided into three parts: some controls on top, aread-only text view on the right, and an info area on the left.With the controls on top, you can do two things: specify the View Commit atwhich the text view will display the file contents, and set how to Highlightthe lines in the text view:

• Change Since The color chosen for a particular line reflects whether the lineis ‘older‘ or ‘newer‘ than the specified Commit.More precisely, the color reflects whether the date when the line was last modifiedlies before or after the date of the commit.
• Age The color chosen for a particular line lies somewhere ‘between‘ the twocolors used for the oldest and the newest commit in which the file was modified,and thus reflects the line‘s relative ‘age‘.You can choose between two age criteria for determining the line color: either Commit Indexwhich refers to the relative position in the relevant commit range (first commit,second commit, etc.) or Time which refers to the commit date, i.e. the pointin time at which the commit was created.
• Author The color chosen for a particular line depends on the author who madethe most recent modification to that line.Each author is mapped to a different color.

The info area shows the commit meta data in a compact format for each lineand consists of following columns:

• SHA short SHA of the commit
• Status will display an ‘~‘-mark if the line has been modified (and not added)and/or an ‘M‘ if the line has been introduced in a merge commit
• Author the initials or a short name of the author
• Date a compact display of the commit date
• Line number the number of the current line

More detailed information for a specific commit will be displayed in the tooltip,when hovering over the info area.The hyperlinks can be used to navigate to the specific commit.

History view

The History of current line view displays the ‘history‘ of the currentlyselected line from the Document view: the ‘history‘ consists of all detectedpast and future versions of the line, as it is present in the selectView Commit.The position of the currently selected line from the Document view is denotedby pale borders surrounding the corresponding line in the History view.

The detection of a link between a past and a future version of aline depends on the changes which have happened in a commit:

• If a certain number of lines has been replaced by exactly the same number of lineswithin a commit, this change will be detected as modification of the correspondinglines and hence they will share the same history.
• If a certain number of lines has been replaced by larger or smaller number of lines,the detection of matching lines depends on the outcome of the internal compare algorithm.For the case where a line has been detected as removed in a commit (insteadof replaced by another line, what might be more appropriate), the historycontains a leading commit after line has been removed entry to which you cannavigate.For the case where a line has been detected as added in a commit (insteadof replacing another line, what might be more appropriate), the history containsa trailing commit before line has been added entry to which you can navigate.

SmartGit STUDY 2