Error could not find git path

error could not find git path

I just installed Flutter SDK, And I got an error Error: Unable to find git in your PATH. when I type flutter --version in CMD. Created attachment 286874 [details] Error log In error log is reported the attached error due to the path where the git icon seems to be searched. developer.vuforia.com › forum › issues-and-bugs › no-git-executable-was-.

Error could not find git path - think, that

A number controlling the amount of output shown by the recursive merge strategy. Overrides merge.verbosity. See git-merge[1]

This environment variable overrides . If it is set to an empty string or to the value "cat", Git will not launch a pager. See also the option in git-config[1].

A number controlling how many seconds to delay before showing optional progress indicators. Defaults to 2.

This environment variable overrides and . It is used by several Git commands when, on interactive mode, an editor is to be launched. See also git-var[1] and the option in git-config[1].

This environment variable overrides the configured Git editor when editing the todo list of an interactive rebase. See also git-rebase[1] and the option in git-config[1].

If either of these environment variables is set then git fetch and git push will use the specified command instead of ssh when they need to connect to a remote system. The command-line parameters passed to the configured command are determined by the ssh variant. See option in git-config[1] for details.

takes precedence over , and is interpreted by the shell, which allows additional arguments to be included. on the other hand must be just the path to a program (which can be a wrapper shell script, if additional arguments are needed).

Usually it is easier to configure any desired options through your personal file. Please consult your ssh documentation for further details.

If this environment variable is set, it overrides Git’s autodetection whether // refer to OpenSSH, plink or tortoiseplink. This variable overrides the config setting that serves the same purpose.

If this environment variable is set, then Git commands which need to acquire passwords or passphrases (e.g. for HTTP or IMAP authentication) will call this program with a suitable prompt as command-line argument and read the password from its STDOUT. See also the option in git-config[1].

If this environment variable is set to , git will not prompt on the terminal (e.g., when asking for HTTP authentication).

Take the configuration from the given files instead from global or system-level configuration files. If is set, the system config file defined at build time (usually ) will not be read. Likewise, if is set, neither nor will be read. Can be set to to skip reading configuration files of the respective level.

Whether to skip reading settings from the system-wide file. This environment variable can be used along with and to create a predictable environment for a picky script, or you can set it temporarily to avoid using a buggy file while waiting for someone with sufficient permissions to fix it.

If this environment variable is set to "1", then commands such as git blame (in incremental mode), git rev-list, git log, git check-attr and git check-ignore will force a flush of the output stream after each record have been flushed. If this variable is set to "0", the output of these commands will be done using completely buffered I/O. If this environment variable is not set, Git will choose buffered or record-oriented flushing based on whether stdout appears to be redirected to a file or not.

Enables general trace messages, e.g. alias expansion, built-in command execution and external command execution.

If this variable is set to "1", "2" or "true" (comparison is case insensitive), trace messages will be printed to stderr.

If the variable is set to an integer value greater than 2 and lower than 10 (strictly) then Git will interpret this value as an open file descriptor and will try to write the trace messages into this file descriptor.

Alternatively, if the variable is set to an absolute path (starting with a / character), Git will interpret this as a file path and will try to append the trace messages to it.

Unsetting the variable, or setting it to empty, "0" or "false" (case insensitive) disables trace messages.

Enables trace messages for the filesystem monitor extension. See for available trace output options.

Enables trace messages for all accesses to any packs. For each access, the pack file name and an offset in the pack is recorded. This may be helpful for troubleshooting some pack-related performance problems. See for available trace output options.

Enables trace messages for all packets coming in or out of a given program. This can help with debugging object negotiation or other protocol issues. Tracing is turned off at a packet starting with "PACK" (but see below). See for available trace output options.

Enables tracing of packfiles sent or received by a given program. Unlike other trace output, this trace is verbatim: no headers, and no quoting of binary data. You almost certainly want to direct into a file (e.g., ) rather than displaying it on the terminal or mixing it with other trace output.

Note that this is currently only implemented for the client side of clones and fetches.

Enables performance related trace messages, e.g. total execution time of each Git command. See for available trace output options.

Enables trace messages for operations on the ref database. See for available trace output options.

Enables trace messages printing the .git, working tree and current working directory after Git has completed its setup phase. See for available trace output options.

Enables trace messages that can help debugging fetching / cloning of shallow repositories. See for available trace output options.

Enables a curl full trace dump of all incoming and outgoing data, including descriptive information, of the git transport protocol. This is similar to doing curl on the command line. See for available trace output options.

When a curl trace is enabled (see above), do not dump data (that is, only dump info lines and headers).

Enables more detailed trace messages from the "trace2" library. Output from is a simple text-based format for human readability.

If this variable is set to "1", "2" or "true" (comparison is case insensitive), trace messages will be printed to stderr.

If the variable is set to an integer value greater than 2 and lower than 10 (strictly) then Git will interpret this value as an open file descriptor and will try to write the trace messages into this file descriptor.

Alternatively, if the variable is set to an absolute path (starting with a / character), Git will interpret this as a file path and will try to append the trace messages to it. If the path already exists and is a directory, the trace messages will be written to files (one per process) in that directory, named according to the last component of the SID and an optional counter (to avoid filename collisions).

In addition, if the variable is set to , Git will try to open the path as a Unix Domain Socket. The socket type can be either or .

Unsetting the variable, or setting it to empty, "0" or "false" (case insensitive) disables trace messages.

This setting writes a JSON-based format that is suited for machine interpretation. See for available trace output options and Trace2 documentation for full details.

In addition to the text-based messages available in , this setting writes a column-based format for understanding nesting regions. See for available trace output options and Trace2 documentation for full details.

By default, when tracing is activated, Git redacts the values of cookies, the "Authorization:" header, the "Proxy-Authorization:" header and packfile URIs. Set this variable to to prevent this redaction.

Setting this variable to will cause Git to treat all pathspecs literally, rather than as glob patterns. For example, running will search for commits that touch the path , not any paths that the glob matches. You might want this if you are feeding literal paths to Git (e.g., paths previously given to you by , diff output, etc).

Setting this variable to will cause Git to treat all pathspecs as glob patterns (aka "glob" magic).

Setting this variable to will cause Git to treat all pathspecs as literal (aka "literal" magic).

Setting this variable to will cause Git to treat all pathspecs as case-insensitive.

When a ref is updated, reflog entries are created to keep track of the reason why the ref was updated (which is typically the name of the high-level command that updated the ref), in addition to the old and new values of the ref. A scripted Porcelain command can use set_reflog_action helper function in to set its name to this variable when it is invoked as the top level command by the end user, to be recorded in the body of the reflog.

If set to , ignore broken or badly named refs when iterating over lists of refs. Normally Git will try to include any such refs, which may cause some operations to fail. This is usually preferable, as potentially destructive operations (e.g., git-prune[1]) are better off aborting rather than ignoring broken refs (and thus considering the history they point to as not worth saving). The default value is (i.e., be paranoid about detecting and aborting all operations). You should not normally need to set this to , but it may be useful when trying to salvage data from a corrupted repository.

If set to a colon-separated list of protocols, behave as if is set to , and each of the listed protocols has set to (overriding any existing configuration). See the description of in git-config[1] for more details.

Set to 0 to prevent protocols used by fetch/push/clone which are configured to the state. This is useful to restrict recursive submodule initialization from an untrusted repository or for programs which feed potentially-untrusted URLS to git commands. See git-config[1] for more details.

For internal use only. Used in handshaking the wire protocol. Contains a colon : separated list of keys with optional values key[=value]. Presence of unknown keys and values must be ignored.

Note that servers may need to be configured to allow this variable to pass over some transports. It will be propagated automatically when accessing local repositories (i.e., or a filesystem path), as well as over the protocol. For git-over-http, it should work automatically in most configurations, but see the discussion in git-http-backend[1]. For git-over-ssh, the ssh server may need to be configured to allow clients to pass this variable (e.g., by using with OpenSSH).

This configuration is optional. If the variable is not propagated, then clients will fall back to the original "v0" protocol (but may miss out on some performance improvements or features). This variable currently only affects clones and fetches; it is not yet used for pushes (but may be in the future).

If set to , Git will complete any requested operation without performing any optional sub-operations that require taking a lock. For example, this will prevent from refreshing the index as a side effect. This is useful for processes running in the background which do not want to cause lock contention with other operations on the repository. Defaults to .

Windows-only: allow redirecting the standard input/output/error handles to paths specified by the environment variables. This is particularly useful in multi-threaded applications where the canonical way to pass standard handles via is not an option because it would require the handles to be marked inheritable (and consequently every spawned process would inherit them, possibly blocking regular Git operations). The primary intended use case is to use named pipes for communication (e.g. ).

Two special values are supported: will simply close the corresponding standard handle, and if is , standard error will be redirected to the same handle as standard output.

(deprecated)

If set to , print an ellipsis following an (abbreviated) SHA-1 value. This affects indications of detached HEADs (git-checkout[1]) and the raw diff output (git-diff[1]). Printing an ellipsis in the cases mentioned is no longer considered adequate and support for it is likely to be removed in the foreseeable future (along with the variable).

When you install msysgit, you are asked in one of the dialogs how your PATH should be modified.

  1. Use Git Bash Only
  2. Run Git from the Windows Command Prompt
  3. Run Git and included Unix tools from the Windows Command Prompt

If you select option 2. (which I guess most users will pick, as option 3. has a scary warning), the directory will be added to the PATH.
If you pick option 3. the directory will also be added.

Now if you run "git --version" from the commandline, it will run , which will call .
I guess Stash tries to run to determine the installed git version.
If you've installed msysgit with option 3. you're fine, as is in your path.
Did you select option 2. you're out of luck as that directory as not added to your path.

The workaround for the user is to either run the msysgit installer again and select option 3. to have your PATH properly set, or edit your PATH manually.

If Stash is indeed calling , this problem will be solved if Stash calls instead.

Unable to find git executable in PATH; please install Git for Windows before retrying. #2617

@Isaac-Tait Editing environment variables manually in this case isn't dangerous, but it's misleading. The Git for Windows installer will have added these environment variables for you automatically— it's a part of its installation process. If you also add these entries manually, they might end up duplicated in your PATH or continue to linger around after you've chosen to uninstall Git for Windows (which should ordinarily cleanup environment variables added by the installer).

In summary: nothing wrong with you personally editing environment variables on your own Windows machine, but I don't want to be circulated online as a solution to this problem because I don't want people to be repeating these manual steps. The solution to every problem so far brought up in this thread is to install Git for Windows using the official installer (or using a package manager like Scoop), not to edit environment variables manually, since the latter can be error-prone.

Beanstalk Guides

Setting up Git can be tricky on Windows compared to Linux or Mac, but if you follow the steps in this guide, you should have no problems using Git on Windows. We’ve done the hard work and chosen between the multiple options at key steps to help make things easier for you. This guide will take you through the steps to install and configure Git and connect it to remote repositories to clone, push, and pull. If you don’t have one already, create a Beanstalk account.

Choosing a Git distribution

There are two competing Git packages for Windows: a Cygwin-based Git and a version called msysGit. We will describe how to install the msysGit package. We recommend installing msysGit because we’ve found it’s easier to work with than the Cygwin based installation.

Installing Git

Once you have downloaded the msysGit executable, double click on it to start the installation wizard. Leave the default directory options. When you get to the “Adjusting your Path environment” setting, select the “Run Git from the Windows Command Prompt” option. Choosing this option will make it easy for you to run Git commands from the Windows Command Prompt (command line) if you choose. Command Prompt is a simple tool, where you can run commands, switch through folders, manage files and it can be ran by selecting in menu, and executing command.

Git Bash

You will notice that for the rest of this article we will use Git Bash for running Git commands. The Git Bash tool works in the same way as the default Windows’ Command Prompt, but has some special features. With Git Bash you’ll be able to use a number of UNIX command line tools along with access to Git, and we recommend it since it’s often simpler to use than the Windows Command Prompt.

You can run it by right clicking your mouse on the desktop, and selecting from pop up window.

When you reach the step “Configuring the line ending conversions”, make sure to leave the option “Checkout Windows-style, commit Unix-style line endings” selected. This option makes sure that Git converts LF to CRLF when checking out text files. When committing text files, CRLF will also be converted to LF. This is a compatibility measure to protect newlines in text files, allowing you to easily work with text files on Windows and on Unix-style platforms.

Important note: The most common problems when setting up Git on Windows are related to SSH keys. Git uses SSH keys to securely access your repositories, and in Windows SSH keys are often searched on the wrong path when you try to use Git.

If you use an older version of msysGit, you may encounter a step called “Choosing the SSH executables”. If you encounter that dialog, we recommend that you choose the “Use OpenSSH” option.

After you have successfully installed Git on Windows, you’ll need to provide secure communication with your Git repositories by creating and installing SSH keys.

Installing SSH keys on Windows

To access your Git repositories you will need to create and install SSH keys. You can do this in two ways:

  • by using OpenSSH (generating SSH keys with which comes with Git)
  • by using PuTTY (free Telnet and SSH client)

OpenSSH and PuTTY are free implementations of Telnet and SSH for Windows. They encrypt all traffic and provide secure communication with your remote Git repositories by using SSH keys.

We recommend OpenSSH over PuTTY, and it’s installed with your Git copy. PuTTY is recommended only for advanced users who are already familiar with how Git with SSH keys work.

Using OpenSSH and generating SSH keys with ssh-keygen

To communicate with the remote Git repository in your Beanstalk account from your Windows computer, you will need to generate an SSH key pair for that computer. This process requires only a few steps, but you do first need to install msysGit using the full installer as described above.

Generating a key pair

To do this you need to run Git Bash, which can be found in your menu. Run the command:

It will ask for location and pass phrase. Accept the default location (usually or ) by pressing . After that, make sure to set a strong pass phrase for the key.

Now that the keys are generated, open the file (found in the default location from the previous step) with a text editor. The contents of this file is your new public key. If you copy it to your clipboard, you can add it to your Beanstalk profile (under the section).

Your SSH public key should look something like this:

In your Beanstalk account, SSH key would look like this:

SSH Key Details in Beanstalk

After you have setup the SSH key on Beanstalk, you should be able to check a connection and then push or pull with your remote Git repository. In case you have trouble with SSH keys check path in your Windows operating system. Some other software can change or environment variable to point to different location, instead of your real home (Documents and Settings) directory.

Checking your connection

Before trying to access your Beanstalk repository, check if the connection to your remote repository works. In order to do that, run Git Bash, and enter this command, replacing with your account name:

In this case, this is the URL to access Git on your Beanstalk account. If you are using another version control hosting service, the URL would be provided by them.

When authenticating or later when trying to connect to Git repository most likely you will encounter a message that looks like this:

You can type and press , which will add your account’s hostname to a file. This step won’t need to be repeated later, unless your public key or your account names changes.

If you were authenticated correctly, you will see a message similar to this one:

You can now continue to configure your local Git profile.

In case you have installed TortoiseGIT

GIT_SSH Variable

If you have ever installed TortoiseGit on the computer you’re setting up your keys on, you may encounter problems. TortiseGit creates an environment variable that configures Plink as your SSH keystore, which may conflict when you try to use Git and SSH. No matter how you change your config or uninstall TortoiseGit, that environment variable persists and until you delete it, Git will not look to your regular directory to find the proper key.

In our case environment variable looked like this: . Environment variables can be found here:

  • Windows XP:
  • Windows 7:

Having problems connecting to your Git repository on Windows 7?

Our users have reported problems when generating SSH keys on Windows 7 systems. If that happens for you, try generating your SSH keys on Windows XP if possible. After generating the private and public keys (following the steps to generate keys are provided above in the Generating a key pair chapter), copy the files to default SSH keys location in Windows 7 (usually or ).

Alternative to OpenSSH — using PuTTY to access your Git repository

Installing Git and using PuTTY to connect to your Git repository can be troublesome, so we recommend that you use the OpenSSH method which we described in the steps above. Using OpenSSH is simple and straightforward, but if OpenSSH is not an option, or for some other reason you prefer to use PuTTY to connect to your repositories, here is a step by step guide on how to do so.

Like OpenSSH, you will generate SSH keys and use them to communicate with your remote Git repositories, only now you will use PuTTY’s tools for generating, storing, and using the keys.

Installing PuTTY

You can download the PuTTY installation package and run it. The latest installation package at the moment of writing this article is putty-0.60-installer.exe which can be found under “A Windows installer for everything except PuTTYtel” heading.

Install PuTTY to the default recommended location, typically . Once installed, navigate to the installation folder where you will find:

  •  – a command-line interface to the PuTTY back ends
  •  – an RSA and DSA key generation utility
  •  – an SSH authentication agent for PuTTY, PSCP and Plink, in which we will store keys
  •  – the Telnet and SSH client

You will also find some other files, but for this guide you only need to know about plink, puttygen, pageant and putty.

Adding GIT_SSH variable to environment

After you have installed PuTTY package, you’ll need to add a variable to your environment variables which should point to the plink.exe file (including its entire path). Accepting our defaults from above, this will likely be:

Environment variables can be found and created/edited here, depending on your version of Windows:

  • Windows XP:
  • Windows 7:

Generating SSH key with puttygen

PuTTY Key Generator

After setting up the environment variable, you need to generate and save SSH keys with puttygen. Run puttygen.exe, which will allow you to generate a SSH-2 RSA public/private keypair. Once generated, save the public and private keys to a folder of your preference, just make sure to note the folder where the keys are shared. Easiest way to remember which is the private/public key is to name them and so you can distinguish them later.

Before leaving puttygen, copy the public key to your clipboard and paste it into your version control hosting account (in Beanstalk, under the section).

Please note that when you generate a key with puttygen, the public key that you copy from puttygen and the public key you save to a file for later use are not in the same format. You can see on the picture below that the public key was saved with new lines and without the “ssh-rsa” keyword. In order to copy and paste the public key to Beanstalk, you need to copy it in the same format as it was when it was generated by puttygen. That format should be: “ssh-rsa keycodegenerated”. All you need to do is modify your key in an editor like Notepad, and then add it to Beanstalk.

Puttygen Public SSH Key Details

Adding your private key to pageant

Pageant Key List

After you have generated the SSH keypair, you need to add the SSH private key to pageant, PuTTY’s key management tool. First, run pageant, which can be found in the directory where you have installed PuTTY package (remember, by default: ). You will see a small icon in your system tray (see the screenshot to the right), which indicates pageant is started. Click on the icon and in pageant window click “Add Keys”. Add the private key that was generated by puttygen in the previous step. The private key has extension .ppk, that is the easiest way to distinguish it from the public key you have created.

After you add the SSH key, you should see it in pageant key list.

Checking your connection

Once you have finished setting up PuTTY, all you need to do is check if the connection to your remote hosted Git repository works if you installed Git.

If you still haven’t installed Git download the msysGit executable, double click on it and the installation wizard should start. Leave the default directory options. When you get to the “Adjusting your Path environment” setting, select the “Use Git Bash only” option. Choosing this option will help you avoid path conflicts.

After you have installed Git run Git Bash and go to the directory where you have installed PuTTY and try to access your repository by typing this:

If you are not authenticated correctly, a message like the following screenshot will pop up:

Putty Error

If you are authenticated correctly, a new window will pop up with message like this:

Pop up window will close shortly after authentication is finished, which means authentication was successful and you should be able to manage your Git repositories from now on.

Setting up Git profile

After you have authenticated correctly by installing Git and setting up SSH keys, before you start using your Git repositories, you should setup your Git profile by typing following after you run Git bash in command line:

In case you are using Beanstalk for version control, it would be best if your first name, last name and email address match to the ones you use in your account to avoid any conflicts.

Summary

In order to be able to use your repository you need to:

  • Install Git
  • Generate SSH keys with PuTTY or ssh-keygen
  • Put keys in correct place (in pageant for PuTTY, in correct folder for OpenSSH)
  • Check if connection to the Git repository is working
  • Setup your Git profile

While setting up Git the most common mistakes include mismatched private and public SSH keys or the user doesn’t have permission to access the repository. If you run into any issues connecting to Beanstalk, don't hesitate to contact us using the links below.

Now what?

Now that you have Git properly installed and configured, you can use a client of your choice. Whether you choose a terminal or a GUI, it is a good idea to learn the basic concepts and commands for versioning your files before. Here’s some recommended reading to get you started:

Igor BalošIgor Baloš is a QA engineer from Novi Sad, Serbia.

Back to Guides

TortoiseGit Manual

To find out what the different settings are for, just leave your mouse pointer a second on the textbox/checkbox... and a helpful tooltip will popup.

Figure 2.72. The Settings Dialog, General Page

The Settings Dialog, General Page


This dialog allows you to specify your preferred language, and the Git-specific settings.

Language

Selects your user interface language. What else did you expect? Only languages of installed language packs are listed. You can download language packs on the TortoiseGit download page or help translating.

Automatically check for newer versions every week

If checked, TortoiseGit will contact its download site once a week to see if there is a newer version of the program available. Use Check now if you want an answer right away. The new version will not be downloaded; you simply receive an information dialog telling you that the new version is available.

Create Library

On Windows 7 you can create a Library in which to group working copies which are scattered in various places on your system.

Git.exe Path

TortoiseGit needs to know which to use for it's operations. Enter the full path to here.

Caution

must not be marked to be run in elevated mode (i.e. Run as administrator or run in any compatibility mode).

Caution

There is a known issue in msysGit/Git for Windows: Git for Windows provides two -files (one in a folder named and one in a folder named ). Make sure Git.exe Path points to the -folder within the Git for Windows installation folder.

Caution

If you don't use Git for Windows, please see the sections for "Cygwin Git" and "MSYS2 Git" below as special settings are required here.

As a general note: There is no official support for Cygwin or MSYS2 Git in TortoiseGit. The TortoiseGit developers only use Git for Windows. Bug reports, however, are welcome.

Tip

In order to debug problems you can open TortoiseGit advanced settings and set to "true" (the section called “Advanced Settings”). Start capturing the debug output. Then start TortoiseGit settings, click on Check now and observe the debug messages.

Extra PATH

If your git installation needs an extra entry in the PATH environment variable, you can enter it here and it will get added to the PATH environment variable automatically when TortoiseGit starts.

This is especially needed if you installed the developer version of msysGit ("Full installer (self-contained) if you want to hack on Git" with the filename ), in this case it is necessary that the -folder is on the path (i.e. entered in the Extra PATH textbox) in order to execute .

Often you can see if you need this when you start in -folder and you get a message box saying that a DLL is missing.

Cygwin Git

As noted above: There is no official support for Cygwin Git in TortoiseGit (do not enable this for the "Git for Windows" package!). The TortoiseGit developers only use Git for Windows. Bug reports, however, are welcome. If you really want to use it, here are the steps you have to perform:

1) Select the -folder as folder.

2) Configure the environment variable in Windows, so that Cygwin and TortoiseGit are using the same home directory and global git-config. Use the normal Windows notation here (e.g., "C:\Users\USERNAME"). By default, TortoiseGit uses the Windows home directory which is normally located under and Cygwin uses its own home directories which are located under .

3) Configure AutoCrLf, this is necessary as TortoiseGit and Cygwin Git have different defaults. The default in Cygwin Git is .

4) Go to TortoiseGit the section called “Advanced Settings” and set to in order to activate Cygwin workarounds.

5) Reboot.

MSYS2 Git

As noted above: There is no official support for MSYS2 Git in TortoiseGit (do not enable this for the "Git for Windows" package!). The TortoiseGit developers only use Git for Windows. Bug reports, however, are welcome. If you really want to use it, here are the steps you have to perform:

1) Select the -folder as folder.

2) Configure the environment variable in Windows, so that MSYS2 and TortoiseGit are using the same home directory and global git-config. Use the normal Windows notation here (e.g., ). By default, TortoiseGit uses the Windows home directory which is normally located under and MSYS2 uses its own home directories which are located under .

3) Configure AutoCrLf, this is necessary as TortoiseGit and MSYS2 Git might have different defaults.

4) Go to TortoiseGit the section called “Advanced Settings” and set to in order to activate MSYS2 workarounds.

5) Reboot.

Figure 2.73. The Settings Dialog, Context Menu Page

The Settings Dialog, Context Menu Page


This page allows you to specify which of the TortoiseGit context menu entries will show up in the main context menu (on the first level), and which entries will appear in the TortoiseGit submenu. By default most items are unchecked and appear in the submenu. If you want to hide specific entries, see the section called “Context Menu 2 Settings”.

Most of the time, you won't need the TortoiseGit context menu, apart for folders that are under version control by Git. For non- versioned folders, you only really need the context menu when you want to do a checkout. If you check the option Hide menus for unversioned paths, TortoiseGit will not add its entries to the context menu for unversioned folders. But the entries are added for all items and paths in a versioned folder. And you can get the entries back for unversioned folders by holding the Shift key down while showing the context menu.

If there are some paths on your computer where you just don't want TortoiseGit's context menu to appear at all, you can list them in the box at the bottom.

If you right click and drag folder/file in Windows Explorer, a context menu will be shown when you drop. It provides some TortoiseGit actions. You can uncheck Enable drag context menu to prevent from carelessly clicking the TortoiseGit actions.

Figure 2.74. The Settings Dialog, Context Menu 2

The Settings Dialog, Context Menu 2


This page allows you to specify which of the TortoiseGit context menu entries will be hidden by default. Selected item will only be visible when you hold the Shift key on right click (this is the so-called extended context menu, please don't mix this with the TortoiseGit submenu, which is also configurable (cf. the section called “Context Menu Settings”)). This configuration helps you to reduce the number of context menu entries according to your needs.

TortoiseGit Dialog Settings

Figure 2.75. The Settings Dialog, Dialogs Page

The Settings Dialog, Dialogs Page


This dialog allows you to configure some of TortoiseGit's dialogs the way you like them.

Font for log messages

Selects the font face and size used to display the log message itself in the middle pane of the Revision Log dialog, and when composing log messages in the Commit dialog.

Short date / time format in log messages

If the standard long messages use up too much space on your screen use the short format.

Show asterisk log prefix

An asterisk is inserted as the prefix of log message in Log dialog.

apply

Normally log entries/commits are ordered in descending order of the commit date. makes the commits appear in topological order (i.e. descendant commits are shown before their parents). Not using this option, might break the graph in the log dialog. However, this option is slower, because all log entries have to be processed before displaying them.

Can double-click in log list to compare with previous revision

If you frequently find yourself comparing revisions in the top pane of the log dialog, you can use this option to allow that action on double-click. It is not enabled by default because fetching the diff is often a long process, and many people prefer to avoid the wait after an accidental double-click, which is why this option is not enabled by default.

Abbreviate renamings

Normally renamed files are listed as . If you check this option renamed files will be listed in a shorter format (), however, this abbreviated format might be harder to understand.

Symbolize ref names

Show symbols on ref labels to substitute part of the ref names in order to make them smaller. If this option is enabled, the following description and example will apply. If there is only a single remote, an up-arrow symbol (↑) will substitute the remote name part of each remote branch. If the remote branch is the upstream of a local branch, an equivalent symbol (≡) will substitute the branch name part of the remote branch.

Figure 2.76. Example of Symbolize ref names

Example of Symbolize ref names
Enable log cache

Load/saves log cache in folder (, ) to boost performance of subsequent use of log list. If this option is disabled, the cache files are not read or written. Default is enabled.

Enable Gravatar

Shows the Gravatar image of the author of the commit in Log Dialog. The URL is customizable so you may specify more options supported by the server, or use your own avatar server. The default URL is Currently, the supported parameter is , which is the MD5 email hash. To specify a default image, add parameter, e.g. See Gravatar: Image Requestsfor a list of parameters.

Draw tag/branch labels on right side

Shows tag/branch labels after the commit message.

Display branch revision number

Displays for every selected commit a so called "branch revision number" in the commit message field of the Log Dialog. The branch revision number is calculated by calling and represents the number of commits between the beginning of time and the selected commit. This number is NOT guaranteed to be unique, especially if you alter the history (e.g., using rebase) or use several branches at the same time. It can be seen "kinda unique" per branch in case you don't alter its history (e.g. by rebasing, resetting) and only commit or merge other branches on it. This number is only displayed for first-parent commits and not for commits on non-fast-forward merges (here duplicate numbers could occur). See https://gcc.gnu.org/ml/gcc/2015-08/msg00148.htmland https://gitlab.com/tortoisegit/tortoisegit/merge_requests/1for more details.

Show describe in log

Shows describe above commit message in the Log dialog. For example, refers to the commit that is 589 commits ahead the tag . Note: Describe may take longer to run if the commit is far ahead away from a tag.

Describe strategy

Determine reference lookup strategy: Available options: Annotated tags, All tags, All refs. Default strategy is annotated tags only. If your repository uses lightweight tags to mark releases, choose All tags.

Describe Abbreviated size

Number of chars of the abbreviated commit id to show in describe. Default is 7.

Describe Always show long format

Whether to use the long format even when a shorter name could be used. For example, when the commit has tag , it still shows long format instead of just .

TortoiseGit Dialog Settings 2

Figure 2.77. The Settings Dialog, Dialogs Page 2

The Settings Dialog, Dialogs Page 2


This dialog allows you to configure some more of TortoiseGit's dialogs the way you like them.

Git.exe Progress Dialog

TortoiseGit can automatically close all progress dialogs when the action is finished without error. This setting allows you to select the conditions for closing the dialogs. The default (recommended) setting is Close manually which allows you to review all messages and check what has happened. However, you may decide that you want to ignore some types of message and have the dialog close automatically if there are no critical changes.

Auto-close if no further options are available will close the dialog if exited cleanly (i.e. no error occurred) and no further options are presented in the progress dialog.

Auto-close if no errors always closes the dialog if exited with 0 error code.

Use recycle bin when reverting

When you revert local modifications, your changes are discarded. TortoiseGit gives you an extra safety net by sending the modified file to the recycle bin before bringing back the pristine copy. If you prefer to skip the recycle bin, uncheck this option.

Confirm to kill running git process

When enabled, if you close Progress Dialog or Sync Dialog with a running git process, you will be asked for confirmation before killing it. This avoids closing the dialog by accident that kills running git process.

Randomize Sync Dialog startup position

When enabled, the startup position of Sync Dialog will be randomized. If you open many Sync Dialogs and press pull button at the same time, you may easily press the pull button in any previous Sync Dialog if it finishes and becomes foreground.

Hide unchanged refs in Ref Compare List

When enabled, unchanged refs will not be shown in Ref Compare List, so you can focus on changed refs. Currently, this list is in Sync Dialog Ref List tab.

Show execution timings and timestamp

When enabled, execution timings and timestamp will be appended at the end of progress message.

Sort tag list in reversed order

When enabled, tag list is sorted in reversed order. It is because newer versions are more useful. e.g. Export Dialog allows to select the latest tag when this option is enabled.

Use auto-completion of file paths and keywords

The commit dialog includes a facility to parse the list of filenames being committed. When you type the first 3 letters of an item in the list, the auto-completion box pops up, and you can press Enter to complete the filename. Check the box to enable this feature.

Timeout in seconds to stop the auto-completion parsing

The auto-completion parser can be quite slow if there are a lot of large files to check. This timeout stops the commit dialog being held up for too long. If you are missing important auto-completion information, you can extend the timeout.

Max. items to keep in the log message history

When you type in a log message in the commit dialog, TortoiseGit stores it for possible re-use later. By default it will keep the last 25 log messages for each repository, but you can customize that number here. If you have many different repositories, you may wish to reduce this to avoid filling your registry.

Note that this setting applies only to messages that you type in on this computer. It has nothing to do with the log cache.

Select items automatically

The normal behavior in the commit dialog is for all modified (versioned) items to be selected for commit automatically. If you prefer to start with nothing selected and pick the items for commit manually, uncheck this box.

TortoiseGit Dialog Settings 3

Figure 2.78. The Settings Dialog, Dialogs 3 Page

The Settings Dialog, Dialogs 3 Page


This dialog allows you to configure some of TortoiseGit's dialogs the way you like them. This third page mainly affects the Commit dialog and the settings which are stored in git config files.

Language

TortoiseGit by default uses the spell checker modules which are also used by OpenOffice, LibreOffice and Mozilla. Optionally, the Windows 8+ spell checker can also be used (needs to be enabled manually at the moment). If you have those installed or use the Windows spell checker this property will determine which spell checker to use, i.e. in which language the log messages for your project should be written. The config key sets the language module the spell checking engine should use when you enter a log message. You can find the values for your language on this page: MSDN: Language Identifiers.

Enter this value in decimal. For example English (US) can be entered as .

Use to disable the spell checker.

Limit

sets the minimum length of a log message for a commit. If you enter a shorter message than specified here, the commit button is disabled. This feature is very useful for reminding you to supply a proper descriptive message for every commit. If this property is not set, or the value is zero, empty log messages are allowed.

Border

is used with projects which require log messages to be formatted with some maximum width (typically 72 characters) before a line break. Setting this property to a non-zero will place a marker to indicate the maximum width and performs line wrapping. Note: this feature will only work correctly if you have a fixed-width font selected for log messages.

Warn on Signed-Off-By on commit

is used with projects which require Signed-off-by line in commit messages.

Overlay Icon

is used with projects which wish to show the logo on the taskbar for easier identification when multiple TortoiseGit application instances of different projects are running at the same time.

If icon is not 16x16 pixels in size, it will be automatically scaled. Supported formats are , , , , . If no icon is included by that project, you may find one on you own, put it in folder and set the relative path in local config. e.g. If you want to disable it, you may set as an empty string in local config. It will fallback to a color block when disabled or load failed. Note that the advanced option should be 3 or 4 in order to use this function.

TortoiseGit color Settings

Figure 2.79. The Settings Dialog, colors Page

The Settings Dialog, colors Page


This dialog allows you to configure the text colors used in TortoiseGit's dialogs the way you like them.

Possible or real conflict / obstructed

A conflict has occurred during update, or may occur during merge. Update is obstructed by an existing unversioned file/folder of the same name as a versioned one.

This color is also used for error messages in the progress dialogs.

Added files

Items added to the repository.

Missing / deleted / replaced

Items deleted from the repository, missing from the working copy, or deleted from the working tree and replaced with another file of the same name.

Merged

Changes from the repository successfully merged into the working tree without creating any conflicts.

Modified / copied

Add with history, or paths copied in the repository. Also used in the log dialog for entries which include copied items.

Note node

A reference which points to git notes, under refs/notes name space.

Use local branch color for current branch

In revision graph, use local branch color for current branch. You may not want to emphasize current branch of a local repository in revision graph.

other settings:

Dark theme

The dialogs in TortoiseGit can be shown in a dark mode on Windows 10 1809 and later. This feature also requires that dark mode for applications is enabled in the Windows 10 settings.

Important

Note that not all controls in all dialogs are shown in a dark theme.

TortoiseGit color Settings 2

Figure 2.80. The Settings Dialog, colors Page

The Settings Dialog, colors Page


This dialog allows you to configure the text colors used in TortoiseGit's dialogs the way you like them.

TortoiseGit color Settings 3

Figure 2.81. The Settings Dialog, colors Page

The Settings Dialog, colors Page


This dialog allows you to configure the line colors, line width and node size in the graph column used in TortoiseGit's log dialog the way you like them.

Figure 2.82. The Settings Dialog, Icon Overlays Page

The Settings Dialog, Icon Overlays Page


This page allows you to choose the items for which TortoiseGit will display icon overlays.

By default, overlay icons and context menus will appear in all open/save dialogs as well as in Windows Explorer. If you want them to appear only in Windows Explorer, check the Show overlays and context menu only in explorer box.

Ignored items and Unversioned items are not usually given an overlay. If you want to show an overlay in these cases, just check the boxes.

You can also choose to mark folders as modified if they contain unversioned items. This could be useful for reminding you that you have created new files which are not yet versioned. This option is only available when you use the default status cache option (see below).

Since it takes quite a while to fetch the status of a working tree, TortoiseGit uses a cache to store the status so the explorer doesn't get hogged too much when showing the overlays. You can choose which type of cache TortoiseGit should use according to your system and working tree size here:

Default

Caches all status information in a separate process (). That process watches all drives for changes and fetches the status again if files inside a working tree get modified. The process runs with the least possible priority so other programs don't get hogged because of it. That also means that the status information is not real time but it can take a few seconds for the overlays to change.

Advantage: the overlays show the status recursively, i.e. if a file deep inside a working tree is modified, all folders up to the working tree root will also show the modified overlay. And since the process can send notifications to the shell, the overlays on the left tree view usually change too.

Disadvantage: the process runs constantly, even if you're not working on your projects. It also uses around 10-50 MB of RAM depending on number and size of your working trees. From version 1.7.0 to 1.7.12 TGitCache did not check the contents of the files, it just checked the last modification time against the time stored in the git index file. Starting from 1.7.13 TGitCache now also checks the contents of the files by default. If you want to restore the old behavior, you can disable checking the contents via the Settings dialog -> Advanced and set to "0".

Shell Extended

Caching is done directly inside the shell extension DLL. Each time you navigate to another folder, the status information is fetched again (recursively).

Advantage: can show the status in real time.

Disadvantage: only one folder is cached and for big working trees, it can take much more time to show a folder in explorer than with the default cache or with shell mode. The Shell variant only shows differences of the filesystem to the git index (does not include revision specific information, e.g. if you remove a file from the index the file will show up as unversioned, but with TGitCache the file will show up as deleted until you commit this change).

Shell

Caching is done directly inside the shell extension DLL, but only for the currently visible folder. Each time you navigate to another folder, the status information is fetched again.

Advantage: needs only very little memory (around 1 MB of RAM) and can show the status in real time.

Disadvantage: Since only one folder is cached, the overlays don't show the status recursively. For big working trees, it can take more time to show a folder in explorer than with the default cache. The Shell variant only shows differences of the filesystem to the git index (does not include revision specific information, e.g. if you remove a file from the index the file will show up as unversioned, but with TGitCache the file will show up as deleted until you commit this change).

None

With this setting, the TortoiseGit does not fetch the status at all in Explorer. Because of that, files don't get an overlay and folders only get a 'normal' overlay if they're versioned. No other overlays are shown, and no extra columns are available either.

Advantage: uses absolutely no additional memory and does not slow down the Explorer at all while browsing.

Disadvantage: Status information of files and folders is not shown in Explorer. To see if your working trees are modified, you have to use the “Check for modifications” dialog.

By default, overlay icons and context menus will appear in all open/save dialogs as well as in Windows Explorer. If you want them to appear only in Windows Explorer, check the Show overlays and context menu only in explorer box.

You can force the status cache to None for elevated processes by checking the Disable status cache for elevated processes box. This is useful if you want to prevent another process getting created with elevated privileges.

You can also choose to mark folders as modified if they contain unversioned items. This could be useful for reminding you that you have created new files which are not yet versioned. This option is only available when you use the default status cache option (see below).

The next group allows you to select which classes of storage should show overlays. By default, only hard drives are selected. You can even disable all icon overlays, but where's the fun in that?

Network drives can be very slow, so by default icons are not shown for working trees located on network shares.

USB Flash drives appear to be a special case in that the drive type is identified by the device itself. Some appear as fixed drives, and some as removable drives.

The Exclude Paths are used to tell TortoiseGit those paths for which it should not show icon overlays and status columns. This is useful if you have some very big working trees containing only libraries which you won't change at all and therefore don't need the overlays, or if you only want TortoiseGit to look in specific folders.

Any path you specify here is assumed to apply recursively, so none of the child folders will show overlays either. If you want to exclude only the named folder, append after the path.

The same applies to the Include Paths. Except that for those paths the overlays are shown even if the overlays are disabled for that specific drive type, or by an exclude path specified above.

Users sometimes ask how these three settings interact. For any given path check the include and exclude lists, seeking upwards through the directory structure until a match is found. When the first match is found, obey that include or exclude rule. If there is a conflict, a single directory spec takes precedence over a recursive spec, then inclusion takes precedence over exclusion.

An example will help here:

Exclude: C: C:\develop\? C:\develop\tgit\obj C:\develop\tgit\bin Include: C:\develop

These settings disable icon overlays for the C: drive, except for . All projects below that directory will show overlays, except the folder itself, which is specifically ignored. The high-churn binary folders are also excluded.

TGitCache.exe also uses these paths to restrict its scanning. If you want it to look only in particular folders, disable all drive types and include only the folders you specifically want to be scanned.

Exclude Drives

It is often convenient to use a drive to access your working trees, e.g. using the command

subst T: C:\TortoiseGit\doc

However this can cause the overlays not to update, as will only receive one notification when a file changes, and that is normally for the original path. This means that your overlays on the path may never be updated.

An easy way to work around this is to exclude the original path from showing overlays, so that the overlays show up on the path instead.

Sometimes you will exclude areas that contain working trees, which saves TGitCache from scanning and monitoring for changes, but you still want a visual indication that a folder contains a working tree. The Show excluded folders as 'normal' checkbox allows you to do this. With this option, working tree folders in any excluded area (drive type not checked, or specifically excluded) will show up as normal and up-to-date, with a green check mark. This reminds you that you are looking at a working tree, even though the folder overlays may not be correct. Files do not get an overlay at all. Note that the context menus still work, even though the overlays are not shown.

As a special exception to this, drives and are never considered for the Show excluded folders as 'normal' option. This is because Windows is forced to look on the drive, which can result in a delay of several seconds when starting Explorer, even if your PC does have a floppy drive.

Figure 2.83. The Settings Dialog, Icon Set Page

The Settings Dialog, Icon Set Page


You can change the overlay icon set to the one you like best. Especially you can disable overlays which you do not need like assume-valid and skip-worktree, however other Tortoise* tools use these two for different purposes. Note that if you change overlay set, you may have to restart your computer for the changes to take effect.

Figure 2.84. The Settings Dialog, Icon Handlers Page

The Settings Dialog, Icon Handlers Page


Because the number of overlays available is severely restricted, you can choose to disable some handlers to ensure that the ones you want will be loaded. Because TortoiseGit uses the common TortoiseOverlays component which is shared with other Tortoise clients (e.g. TortoiseSVN, TortoiseCVS, TortoiseHg) this setting will affect those clients too.

For a description of how icon overlays correspond to Git status and other technical details, read the section called “Icon Overlays”.

Windows explorer can just handle a fixed number different overlay providers (15) and TortoiseGit is using 6 of these (these 6 are handled by TortoiseOverlays and, thus, shared with TortoiseSVN and TortoiseCVS). If the TortoiseGit icons are not correctly displayed this is likely caused by other programs which provide overlays (like DropBox, Owncloud, BoxSync and various others) and register with a higher priority. Use the Start registry editor button for opening the registry editor at the key where the overlay handlers are registered. Just delete or rename the ones you don't need OR prepend the ones with a double quote or space characters so that those come first in the list. For more information please see TortoiseGit FAQ.

Figure 2.85. The Settings Dialog, Network Page

The Settings Dialog, Network Page


Here you can configure your proxy server, if you need one to get through your company's firewall.

The proxy server settings here do only affect Git for Windows (i.e., HTTP and HTTPS protocols). If you are using OpenSSH/PuTTY/Tortoise(Git)Plink you have to set up the proxy server settings there separately. In order to do this, you need the main PuTTY tool, which is not shipped with TortoiseGit. Preferably you store the proxy settings to the "Default Settings" configuration there, so that it is applied by default.

If you need to set up per-repository proxy settings, you will need to use the Git file to configure this. Consult the section called “git-config(1)” for more details.

You can also specify which program TortoiseGit should use to establish a secure connection to a git repository which is access using SSH. We recommend that you use TortoiseGitPlink.exe. This is a version of the popular Plink program, and is included with TortoiseGit, but it is compiled as a Windowless app, so you don't get a DOS box popping up every time you authenticate.

You must specify the full path to the executable. For TortoiseGitPlink.exe this is the standard TortoiseGit bin directory. Use the Browse button to help locate it, e.g.:

"C:\Program Files\TortoiseGit\bin\TortoiseGitPlink.exe"

Tip

If you want to use OpenSSH shipped by Git for Windows/msysGit just enter .

One side-effect of not having a window is that there is nowhere for any error messages to go, so if authentication fails you will simply get a message saying something like “Unable to write to standard output”. For this reason we recommend that you first set up using standard Plink. When everything is working, you can use TortoiseGitPlink with exactly the same parameters.

TortoiseGitPlink does not have any documentation of its own because it is just a minor variant of Plink. Find out about command line parameters from the PuTTY website

To avoid being prompted for a password repeatedly, you might also consider using a password caching tool such as Pageant. This is also available for download from the PuTTY website or included in the TortoiseGit package. (Also see the section called “Authentication”.)

Finally, setting up SSH on clients is a non-trivial process which is beyond the scope of this help file. However, you can find a guide in the TortoiseGit FAQ listed under Appendix F, Tips and tricks for SSH/PuTTY.

Figure 2.86. The Settings Dialog, email settings

The Settings Dialog, email settings


This page allows you to specify configure how mails should be send.

SMTP, directly to destination server

When this option is selected, TortoiseGit directly connects to the SMTP server(s) (on port 25) which is/are responsible for the specific destination email-address(es). This is the default for TortoiseGit (unless some different method is configured).

Important

This might be problematic if your ISP blocks outgoing SMTP connections (port 25) or you have a dial-up internet connection. In the ladder case some destination MTAs might not accept your mails or mark them as SPAM.

MAPI

When this option is selected, TortoiseGit uses the Microsoft Messaging API (MAPI) for sending mails. For this, you need a MAPI capable mail client (e.g. Thunderbird or Outlook).

Important

If you don't send patches as attachments, you might need to make sure that no auto line wrapping takes place. For Thunderbird there is an add-on (Toggle Word Wrap) available.

use configured server

This is the recommended way for sending mails. Just enter the same data as in your mail tools (MUA).

External Program Settings

Here you can define your own programs that TortoiseGit should use. The default setting is to use tools which are installed alongside TortoiseGit.

Read the section called “External Diff/Merge Tools” for a list of some of the external diff/merge programs that people are using with TortoiseGit.

Figure 2.87. The Settings Dialog, Diff Viewer Page

The Settings Dialog, Diff Viewer Page

An external diff program may be used for comparing different revisions of files. The external program will need to obtain the filenames from the command line, along with any other command line options. TortoiseGit uses substitution parameters prefixed with . When it encounters one of these it will substitute the appropriate value. The order of the parameters will depend on the Diff program you use.

%base

The original file without your changes

%bname

The window title for the base file

%mine

Your own file, with your changes

%yname

The window title for your file

%bpath

Full path to the original file

%ypath

Full path to your file

%brev

The revision of the original file, if available

%yrev

The revision of the second file, if available

%wtroot

Path to the working tree

The window titles are not pure filenames. TortoiseGit treats that as a name to display and creates the names accordingly. So e.g. if you're doing a diff from a file in revision 123 with a file in your working tree, the names will be and

For example, with ExamDiff Pro:

C:\Path-To\ExamDiff.exe %base %mine --left_display_name:%bname --right_display_name:%yname

or with KDiff3:

C:\Path-To\kdiff3.exe %base %mine --L1 %bname --L2 %yname

or with WinMerge:

C:\Path-To\WinMerge.exe -e -ub -dl %bname -dr %yname %base %mine

or with Araxis:

C:\Path-To\compare.exe /max /wait /title1:%bname /title2:%yname %base %mine

If you have configured an alternate diff tool, you can access TortoiseGitMerge and the third party tool from the context menus. → uses the primary diff tool, and Shift+ → uses the secondary diff tool.

Unified-Diff/GNU Diff/Patch File Viewer

Instead of TortoiseGitUDiff an external viewer program for unified-diff files (GNU diff or patch files) may be used. Basically, there is no parameter required - the file name if the unified diff file to be opened will be appended automatically. If you need to pass it as a different parameter the substitution can be used. There also is the parameter substitution available for passing the title to be shown in the title bar (i.e., meta data of the diff).

For example, with Notepad2 (shipped with TortoiseGit):

Notepad2.exe /s "Diff Files" /t %title

or (equivalent)

Notepad2.exe /s "Diff Files" /t %title %1

If you have configured an alternate unified diff tool, you can access TortoiseGitUDiff and the third party tool from the context menus. When you hold the Shift-key while opening the context menu the secondary unified diff tool is started.

Figure 2.88. The Settings Dialog, Merge Tool Page

The Settings Dialog, Merge Tool Page

An external merge program used to resolve conflicted files. Parameter substitution is used in the same way as with the Diff Program.

%base

the original file without your or the others changes

%bname

The window title for the base file

%mine

your own file, with your changes

%yname

The window title for your file

%theirs

the file as it is in the repository

%tname

The window title for the file in the repository

%merged

the conflicted file, the result of the merge operation

%mname

The window title for the merged file

%wtroot

Path to the working tree

For example, with Perforce Merge:

C:\Path-To\P4Merge.exe %base %theirs %mine %merged

or with KDiff3:

C:\Path-To\kdiff3.exe %base %mine %theirs -o %merged --L1 %bname --L2 %yname --L3 %tname

or with Araxis:

C:\Path-To\compare.exe /max /wait /3 /title1:%tname /title2:%bname /title3:%yname %theirs %base %mine %merged /a2

or with WinMerge (2.12 or later):

C:\Path-To\WinMergeU.exe /e /ub /fr /wl /wm /dl %bname /dm %tname /dr %yname %base %theirs %mine /o %merged /ar

TortoiseGit creates temporary files with similar file names as the conflicted file (, and ). These files are automatically removed when the conflict is marked as resolved using TortoiseGit, TortoiseGitMerge, or TortoiseGitIDiff.

When using an external tool, a conflicted file needs to be marked as revolved in TortoiseGit manually (doing so also removes the temporary files). This can be simplified and might also be automated: TortoiseGit can be configured to synchronously executing the merge tool (Block TortoiseGit while executing the external merge tool). Then TortoiseGit waits until the external merge tool is closed and asks whether to resolve the conflict (the temporary files are removed in any case). If the external merge tool provides a proper exit code (0 for success) you can trust the exit code to automatically mark the conflicted file as resolved (as Git does, cf. the section called “git-mergetool(1)”).

Diff/Merge Advanced Settings

Figure 2.89. The Settings Dialog, Diff/Merge Advanced Dialog

The Settings Dialog, Diff/Merge Advanced Dialog


In the advanced settings, you can define a different diff and merge program for every file extension. For instance you could associate Photoshop as the “Diff” Program for files :-)

To associate using a file extension, you need to specify the extension. Use to describe Windows bitmap files.

Figure 2.90. The Settings Dialog, Alternative editor Page

The Settings Dialog, Alternative editor Page

The original Windows Notepad program does not behave well on files which do not have standard CR-LF line-endings. However, a lot of git configuration files do not have a standard CR-LF line-ending. Because of this TortoiseGit uses a free (shipped) Notepad replacement Notepad2which displays the line-endings correctly by default.

Figure 2.91. The Settings Dialog, Saved Data Page

The Settings Dialog, Saved Data Page


For your convenience, TortoiseGit saves many of the settings you use, and remembers where you have been lately. If you want to clear out that cache of data, you can do it here.

URL history

Whenever you checkout a working tree, merge changes or use the repository browser, TortoiseGit keeps a record of recently used URLs and offers them in a combo box. Sometimes that list gets cluttered with outdated URLs so it is useful to flush it out periodically.

If you want to remove a single item from one of the combo boxes you can do that in-place. Just click on the arrow to drop the combo box down, move the mouse over the item you want to remove and type Shift+Del.

Log messages (Input dialog)

TortoiseGit stores recent commit log messages that you enter. These are stored per repository, so if you access many repositories this list can grow quite large.

Log messages (Show log dialog)

TortoiseGit caches log messages fetched by the Show Log dialog to save time when you next show the log. If someone else edits a log message and you already have that message cached, you will not see the change until you clear the cache. Log message caching is enabled on the Log Cache tab.

Dialog sizes and positions

Many dialogs remember the size and screen position that you last used.

Action log

TortoiseGit keeps a log of everything written to its progress dialogs. This can be useful when, for example, you want to check what happened in a recent update command.

The log file is limited in length and when it grows too big the oldest content is discarded. By default 4000 lines are kept, but you can customize that number.

From here you can view the log file content, and also clear it.

The log file is located at .

The hierarchical Git configuration

Git uses the concept of a hierarchical configuration (cf. the section called “git-config(1)”). I.e. there are multiple levels; settings in higher levels override values in lower levels. The Effective tab shows you the effective values for the current scope (read-only).

Select any level (e.g. Local - the current repository settings stored locally in , Project - settings for the current repository stored within the repository in , Global - settings for the current user, System - settings for all users of the system) to see the values stored there.

In order to change settings select a level, enter the values, select where to store to and click on Apply.

Caution

If you want to inherit a value of a higher level don't leave a textbox empty (this means than an empty string will be stored, which might evaluate to ), select Inherit instead.

Figure 2.92. The Settings Dialog, Git

The Settings Dialog, Git

Set git basic configuration

Name and Email are required for git to operate correctly.

AutoCrLf If true, makes git convert CRLF at the end of lines in text files to LF when reading from the filesystem, and convert in reverse when writing to the filesystem. The variable can be set to input, in which case the conversion happens only while reading from the filesystem but files are written out with LF at the end of lines. A file is considered "text" (i.e. be subjected to the AutoCrLf mechanism) based on the file's CRLF attribute, or if CRLF is unspecified, based on the file's contents.

SafeCrLf If true, makes git check if converting CRLF as controlled by is reversible. Git will verify if a command modifies a file in the work tree either directly or indirectly. For example, committing a file followed by checking out the same file should yield the original file in the work tree. If this is not the case for the current setting of , git will reject the file. The variable can be set to "warn", in which case git will only warn about an irreversible conversion but continue the operation.

QuotePath Controls the setting which might be interesting when you have non ASCII filenames: See the section called “git-config(1)”.

Figure 2.93. The Settings Dialog, Git, Remote

The Settings Dialog, Git, Remote

Set Git remote configuration

Remote The name of the remote, usually the default one is called .

URL The URL of the remote. It can be HTTP / HTTPS / SSH / Git protocol or local file system.

Push URL The Push URL of the remote. It is for some cases you cannot use the same URL to fetch and push (for example, fetch via password-less Git protocol but push via SSH). Otherwise, leave it empty. Note: This is not designed for forking workflow. For forking workflow, you should have 2 remotes. The format is the same as URL.

Putty Key The putty key file to load when performing network operations.

Tag This sets config, which controls the default tag fetching behavior of the specified remote. : Download tags that are reachable from remote branch heads (default behavior). : No tags are downloaded (). (git 1.9 and later) : All tags as well as branches are downloaded (). (prior to git 1.9) : Only all tags are downloaded but no branches are downloaded (). Use case of : Always fetch tags from a git-svn mirror. Subversion tags never exist on trunk, so such tags are not reachable from branch heads.

Push Default Selecting this means to always push to this remote (cf. the section called “git-config(1)”) Default is false.

Prune This sets config, which controls the default prune option of remote tracking branches of the specified remote. Default is false.

Figure 2.94. The Settings Dialog, Git, Credential

The Settings Dialog, Git, Credential

Set simple credential helper configuration

Advanced This is used if the credential helper configuration does not match any simple settings. If you choose other than , except the corresponding , all other config keys or are removed.

None No credential config keys are in all config levels.

manager-core - this repository only Git Credential Manager Core (manager-core; https://github.com/microsoft/Git-Credential-Manager-Core) is enabled in local config only. This option is visible only if manager-core is installed.

manager - this repository only Git Credential Manager (manager; https://github.com/microsoft/Git-Credential-Manager-for-Windows) is enabled in local config only. This option is visible only if manager is installed.

wincred - this repository only wincred is enabled in local config only. This option is visible only if wincred is installed.

winstore - this repository only winstore is enabled in local config only. This option is visible only if winstore is installed for current Windows user.

manager-core - current Windows user Git Credential Manager Core (manager-core; https://github.com/microsoft/Git-Credential-Manager-Core) is enabled in global config only. This option is visible only if manager-core is installed.

manager - current Windows user Git Credential Manager (manager; https://github.com/microsoft/Git-Credential-Manager-for-Windows) is enabled in global config only. This option is visible only if manager is installed.

wincred - current Windows user wincred is enabled in global config only. This option is visible only if wincred is installed.

winstore - current Windows user winstore is enabled in global config only. This option is visible only if winstore is installed for current Windows user.

manager-core - all Windows users Git Credential Manager Core (manager-core; https://github.com/microsoft/Git-Credential-Manager-Core) is enabled in system config only. This option is visible only if manager-core is installed. Change to this option requires administrator privileges.

manager - all Windows users Git Credential Manager (manager; https://github.com/microsoft/Git-Credential-Manager-for-Windows) is enabled in system config only. This option is visible only if manager is installed. Change to this option requires administrator privileges.

wincred - all Windows users wincred is enabled in system config only. This option is visible only if wincred is installed. Change to this option requires administrator privileges.

Advanced credential helper configuration

Config type Either Local, Global or System config.

URL Define a context-specific configuration based on URL pattern. By default, the path component is not considered as a different context.

Helper Select a credential helper program. manager-core, manager, wincred, and winstore are predefined in TortoiseGit. It is possible to use other credential helpers or with extra options.

Username A default username, if one is not provided in the URL.

Use HTTP path component Also considers the path component of URL to match the configuration context.

You can find more information at the section called “gitcredentials(7)”.

Figure 2.95. The Settings Dialog, Hook Scripts Page

The Settings Dialog, Hook Scripts Page


This dialog allows you to set up hook scripts which will be executed automatically when certain TortoiseGit actions are performed on the client side.

For various security and implementation reasons, hook scripts are defined locally on a machine, rather than as project properties. You define what happens, no matter what someone else commits to the repository. Of course you can always choose to call a script which is itself under version control.

One application for such hooks might be to call a program like (Chapter 3, The GitWCRev Program) to update version numbers after a commit, and perhaps to trigger a rebuild.

Figure 2.96. The Settings Dialog, Configure Hook Scripts

The Settings Dialog, Configure Hook Scripts


To add a new hook script, simply click Add and fill in the details.

There are currently six types of hook script available

Start-commit

Called before the commit dialog is shown. You might want to use this if the hook modifies a versioned file and affects the list of files that need to be committed and/or commit message. However you should note that because the hook is called at an early stage, the full list of objects selected for commit is not available.

Pre-commit

Called after the user clicks OK in the commit dialog, and before the actual commit begins. This hook has a list of exactly what will be committed.

Post-commit

Called after the commit finished successfully.

Pre-push

Called before actual Git push begins.

Post-push

Called after pushing finishes (whether successful or not).

Pre-rebase

Called before rebasing starts (after clicking on Start or autostart).

A hook is defined for a particular working tree path. You only need to specify the top level path; if you perform an operation in a sub-folder, TortoiseGit will automatically search upwards for a matching path. Use for matching all working trees.

If the checkbox Run for this repository is checked then the hook script is attached to the current repository and configured automatically for every clone and checkout (the hook information is stored in the file in the repository root so that it will be automatically shared with all other developers using TortoiseGit >= 2.7.1; for security reasons TortoiseGit asks the user before running a hook which is configured and shared in the repository). In this case, you can specify paths for the command line with the replacement string for the path to the working tree folder. The hook script has to be inside the repository and also be checked out of course (please also note the security implications below). If a user locally configures a hook for the exact repository root folder, the client side defined hook takes precedence.

Next you must specify the command line to execute, starting with the path to the hook script or executable. This could be a batch file, an executable file or any other file which has a valid windows file association, e.g. a perl script.

The command line includes several parameters which get filled in by TortoiseGit. The parameters passed depend upon which hook is called. Each hook has its own parameters which are passed in the following order:

Start-commit
Pre-commit
Post-commit
Pre-push
Post-push
Pre-rebase

The meaning of each of these parameters is described here:

PATH

A path to a temporary file which contains all the paths for which the operation was started in UTF-8 encoding. Each path is on a separate line in the temp file.

MESSAGEFILE

Path to a file containing the log message for the commit. The file contains the text in UTF-8 encoding. After successful execution of the start-commit and pre-commit hooks, the log message is read back, giving the hook a chance to modify it.

ERROR

Path to a file containing the error message. If there was no error, the file will be empty.

CWD

The current working directory with which the script is run. This is set to the working tree root.

Note that although we have given these parameters names for convenience, you do not have to refer to those names in the hook settings. All parameters listed for a particular hook are always passed, whether you want them or not ;-)

If you want the Git operation to hold off until the hook has completed, check Wait for the script to finish.

Normally you will want to hide ugly DOS boxes when the script runs, so Hide the script while running is checked by default.

Caution

If you are executing a versioned file/script from the repository, please note that the file possibly gets altered by third parties unnoticed (e.g. after pull or merge).

Issue Tracker Integration

TortoiseGit can use a COM plugin to query issue trackers when in the commit dialog. The use of such plugins is described in the section called “Getting Information from the Issue Tracker”. If your system administrator has provided you with a plugin, which you have already installed and registered, this is the place to specify how it integrates with your working tree.

Tip

There is also a hierarchical git configuration to associate issue tracker plugin with your project, rather than with to a specific directory path. Such settings are more portable. See the section called “Integration with Bug Tracking Systems / Issue Trackers” to configure these settings.

Figure 2.97. The Settings Dialog, Issue Tracker Integration Page

The Settings Dialog, Issue Tracker Integration Page
The Settings Dialog, Issue Tracker Integration Page


Click on Add... to use the plugin with a particular working tree. Here you can specify the working tree path, choose which plugin to use from a drop down list of all registered issue tracker plugins, and any parameters to pass. The parameters will be specific to the plugin, but might include your user name on the issue tracker so that the plugin can query for issues which are assigned to you.

TortoiseGitBlame Settings

Figure 2.99. The Settings Dialog, TortoiseGitBlame Page

The Settings Dialog, TortoiseGitBlame Page


The settings used by TortoiseGitBlame are controlled from the main context menu, not directly with TortoiseGitBlame itself. Details for the parameters for the blame algorithm are described in the section called “git-blame(1)”.

Colors

TortoiseGitBlame can use the background color to indicate the age of lines in a file. You set the endpoints by specifying the colors for the newest and oldest revisions, and TortoiseGitBlame uses a linear interpolation between these colors according to the repository revision indicated for each line.

Font

You can select the font used to display the text, and the point size to use. This applies both to the file content, and to the author and revision information shown in the left pane.

Tab size

Defines how many spaces to use for expansion when a tab character is found in the file content.

Detect moved or copied lines

Disabled Traditional blame algorithm, the search for parents is limited to the file and will follow renames.

Within file Extra passes of inspection are applied to detect moved and copied lines within the file ().

From modified files In addition to the annotated file detect moved or copied lines from all modified files within a commit ().

At file creation In addition to the annotated file and the modified files within a commit detect moved or copied lines from other files in the commit that creates the file ().

From existing files In addition detect moved or modified lines from other files in any commit ().

Number of characters required for moved or copied line detection

Lower bound on the number of alphanumeric characters that Git must detect as moving/copying between files for it to associate those lines with the parent commit.

Within a file Number of alphanumeric characters required to detect moving lines within a file ().

Between files Number of alphanumeric characters required to detect moved or copied lines between files ().

Ignore whitespace

Defines if whitespace is ignored when comparing the parent's version and the child's version to find where the lines came from ().

Show complete log

Defines if the log should be complete, i.e. the log contains all changes for a file, even the changes have no impact on the file content of the annotated revision. If deactivated the log contains only revisions which last modified a line for the annotated revision.

Follow renames

Defines if the log should follow renames, i.e. if the log does not stop when a file was renamed in the past, but include all changes before the rename.

TortoiseGitUDiff Settings

Figure 2.100. The Settings Dialog, TortoiseGitUDiff Page

The Settings Dialog, TortoiseGitUDiff Page


The settings used by TortoiseGitUDiff are controlled from the main context menu, not directly with TortoiseGitUDiff itself.

Colors

The default colors used by TortoiseGitUDiff are usually a good choice, but you can configure them here.

Font

You can select the font used to display the text, and the point size to use.

Tabs

Defines how many spaces to use for expansion when a tab character is found in the file diff.

To select whether you would like to use the build-in or any alternative diff viewer program go to the section called “External Program Settings” preferences section in the leftward tree.

A few infrequently used settings are available only in the advanced page of the settings dialog. These settings modify the registry directly and you have to know what each of these settings is used for and what it does. Do not modify these settings unless you are sure you need to change them.

AutoCompleteMinChars

The minimum amount of chars from which the editor shows an auto-completion popup. The default value is .

AutocompleteParseMaxSize

The auto-completion list shown in the commit message editor can parse source code files and displays methods and variable names. This limits files to be parsed by their size in bytes. The default value is .

AutocompleteParseUnversioned

The auto-completion list shown in the commit message editor can parse source code files and displays methods and variable names. By default only versioned files are parsed. Set this value to in order to also parse unversioned files.

AutocompleteRemovesExtensions

The auto-completion list shown in the commit message editor displays the names of files listed for commit. To also include these names with extensions removed, set this value to .

BlockStatus

If you don't want the explorer to update the status overlays while another TortoiseGit command is running (e.g. Update, Commit, ...) then set this value to .

CacheTrayIcon

To add a cache tray icon for the TGitCache program, set this value to . This is really only useful for developers as it allows you to terminate the program gracefully.

CacheSave

To disable loading and saving cache for the TGitCache program, set this value to . This is useful if you do not want to write the cache to disk, which can be a large file. The default is .

ConflictDontGuessBranchNames

When merging a conflict, TortoiseGit tries to find a friendly branch name for the context menu and for the title in TortoiseGitMerge to make merging easier. As Git does only stores the as a commit hash, TortoiseGit has to guess the branch name (cf. issue #3700) which might be wrong if a commit has several branches. You can use this option to disable this heuristic. The default is .

CygwinHack

This enables some workarounds which enables TortoiseGit to be used with Cygwin Git. Cygwin Git, however, is not officially supported by TortoiseGit. See the section called “General Settings” for more information. The default is .

Debug

Set this to if you want a dialog to pop up for every command showing the command line used to start TortoiseGitProc.exe.

DebugOutputString

Set this to if you want TortoiseGit to print out debug messages during execution. The messages can be captured with special debugging tools only (like Debug View from the SysInternals Suite).

DiffSimilarityIndexThreshold

This setting controls which similarity index threshold is passed to git diff (as the value for the parameters and in per cent, cf. in the section called “git-diff(1)”). The default value is . You can disable finding renamed and copied files by setting this to , for only detecting exact renames use . You might need to remove the cache files and in the folders after changing this value.

DownloadAnimation

When performing or remote operations TortoiseGit dialogs play an animation with a flying turtle. This setting allows to disable the playing of the animation by setting it to . The default value is .

FullRowSelect

The status list control which is used in various dialogs (e.g., commit, check-for-modifications, add, revert, ...) uses full row selection (i.e., if you select an entry, the full row is selected, not just the first column). This is fine, but the selected row then also covers the background image on the bottom right, which can look ugly. To disable full row select, set this value to .

GroupTaskbarIconsPerRepo

This option determines how the Win7 taskbar icons of the various TortoiseGit dialogs and windows are grouped together.

  1. The default value is . With this setting, the icons are grouped together by application type per working tree. All dialogs from TortoiseGit of one working tree are grouped together, all windows from TortoiseGitMerge of one working tree are grouped together, ... For example, if you have a log dialog and a push dialog open for working tree , and a check-for-modifications dialog and a log dialog for working tree , then there are two application icon groups shown in the Win7 taskbar, one group for each working tree. But TortoiseGitMerge windows are not grouped together with TortoiseGit dialogs.

    Figure 2.101. Taskbar with default grouping

    Taskbar with default grouping
  2. If set to , then the grouping works as with the setting set to , except that TortoiseGit, TortoiseGitMerge, TortoiseGitBlame, TortoiseGitIDiff and TortoiseGitUDiff windows of one working tree are all grouped together. For example, if you have the log dialog open and then double click on a modified file, the opened TortoiseGitMerge diff window will be put in the same icon group on the taskbar as the log dialog icon.

    Figure 2.102. Taskbar with repository grouping

    Taskbar with repository grouping
  3. If set to , then the grouping works as with the setting set to (grouping by application), except that grouping takes place independently of the working tree. This was the default before TortoiseGit 1.8.1.2.

  4. If set to , then the grouping works as with the setting set to , except that grouping takes place independently of the working tree. Thus all TortoiseGit icons are grouped to only show one icon.

GroupTaskbarIconsPerRepoOverlay

This has no effect if the option is set to (see above).

If this option is set to , then every icon on the Win7 taskbar shows a small colored rectangle overlay, indicating the working tree the dialogs/windows are used for.

Figure 2.103. Taskbar grouping with repository color overlays

Taskbar grouping with repository color overlays
LogIncludeWorkingTreeChanges

This options controls whether the log dialog includes an entry for "Working Tree Changes". When using network drives (e.g., Samba), the log dialog might hang for big project because of large of files when calculating the working tree changes. Therefore, the possible expensive calculation can be disabled. The default is .

LogShowSuperProjectSubmodulePointer

This option defines whether the commit of a submodule to which the super repository points to is highlighted with a branch like label (cf. issue #2826). The default is .

LogTooManyItemsThreshold

In order to prevent delays displaying the files on a revision on the log dialog there is a maximum of items to be displayed enforced. The default is .

MaxRefHistoryItems

This options sets the maximum browse ref history (Right click ref hyperlink to find it). The default is .

Msys2Hack

This enables some workarounds which enables TortoiseGit to be used with MSYS2 Git (do not enable this for the Git for Windows package!). MSYS2 Git, however, is not officially supported by TortoiseGit. See the section called “General Settings” for more information. The default is .

NamedRemoteFetchAll

When set to , and don't fetch the default refspec for a named remote. The default is .

NoSortLocalBranchesFirst

This option toggles if the branches are sorted fully by name () or if local branches should appear above remote ones (git default, ). The default value is .

NumDiffWarning

If you want to show the diff at once for more items than specified with this settings, a warning dialog is shown first. The default is .

OverlaysCaseSensitive

Starting with TortoiseGit 2.4.0 the overlay icons are case sensitive on filenames. The change was introduced to fix several issues related to casing (such as issue #2654) and git tools (such as ) being case sensitive on paths. Upon issue #2980 this is configurable starting from TortoiseGit 2.5.0, however, enabling is not recommended. The default is .

ProgressDlgLinesLimit

The Git progress dialog shows the output of the executed commands. The number of lines are limited for performance reasons. The default is , minimum is .

ReaddUnselectedAddedFilesAfterCommit

This option toggles the re-adding of unselected added files after a commit. Up to TortoiseGit 1.7.10 added files which were not checked on a commit, were removed from the index and unversioned after the commit. Set this value to to restore the old behavior. Set this value to to re-add these files again after the commit (default).

RefreshFileListAfterResolvingConflict

This option toggles whether the file lists of the commit dialog, resolve conflicts and rebase dialog automatically refresh when a conflict is marked as resolved. By default this is set to , but in certain cases, e.g. when refreshing takes lots of time or you want to prevent the scrolling to the top, this can be set to . However, then a manual refresh (e.g. by pressing F5) is necessary.

RememberFileListPosition

This option toggles whether the file lists of the add, commit, revert, resolve and rebase dialog remember the last selected line on a refresh. The default is .

SanitizeCommitMsg

This option trims space, CR, LF characters at the end of commit messages you enter. This covers commit, rebase, notes, annotated tag. This value is by default. If such trimming breaks your scripts/plugins, you can disable trimming by set it to .

ScintillaDirect2D

This option enables the use of Direct2D accelerated drawing in the Scintilla control which is used as the edit box in e.g. the commit dialog (also for the attached patch window), the unified diff viewer and TortoiseGitBlame. With some graphic cards, however, this sometimes doesn't work properly so that the cursor to enter text isn't always visible, the redraw does not work or the background is flashing. It's disabled by default. You can turn this feature on by setting this value to .

ShellMenuAccelerators

TortoiseGit uses accelerators for its explorer context menu entries. Since this can lead to doubled accelerators (e.g. the has the Alt-C accelerator, but so does the entry of explorer). If you don't want or need the accelerators of the TortoiseGit entries, set this value to .

ShortHashLengthForHyperLinkInLogMessage

The minimum length of commit hashes that TortoiseGit shows hyper-link for in log messages. Default is .

ShowContextMenuIcons

This can be useful if you use something other than the windows explorer or if you get problems with the context menu displaying incorrectly. Set this value to if you don't want TortoiseGit to show icons for the shell context menu items. Set this value to to show the icons again.

ShowAppContextMenuIcons

If you don't want TortoiseGit to show icons for the context menus in its own dialogs, set this value to .

ShowListBackgroundImage

If you do not want to have a small background image in list controls (e.g. Commit Dialog) set this value to . Set this value to to show the images again (default).

SquashDate

Using this setting you can control which date is used on squashing commits. Set this value to if you want to use the date of the latest commit. Set this value to if you want to use the current date. Set this value to to use the date of the first commit (into which all others are squashed, default).

StyleCommitMessages

The commit and log dialog use styling (e.g. bold, italic) in commit messages (see the section called “Commit Log Messages” for details). If you don't want to do this, set the value to .

TGitCacheCheckContentMaxSize

TGitCache checks the content of files by hashing them and comparing the SHA1 in order to calculate the file statuses if the timestamps (to index) mismatch. This option allows to restrict this behavior for files which do not exceed a specific size (in KiB). The default maximum file size is 10 MiB (i.e., 10 * 1024 KiB = KiB). Set this to 0 in order to make TGitCache only check the timestamps (as TortoiseGit 1.7.0 up to 1.7.12 did; before TortoiseGit 1.9.0.0 this was controlled by ). Disabling checking the file contents can lower disk access and CPU time of the TGitCache process, however, overlay accuracy might not be as accurate as with checking of the file contents enabled.

UseCustomWordBreak

The standard edit controls do not stop on forward slashes like they're found in paths and URLs. TortoiseGit uses a custom word break procedure for the edit controls. If you don't want that and use the default instead, set this value to 0. If you only want the default for edit controls in combo boxes, set this value to 1.

UseLibgit2

This makes TortoiseGit to use libgit2 as much as possible (e.g. for adding files to the index). If you do not want TortoiseGit to use libgit2 for file operations, set this value to .

VersionCheck

TortoiseGit checks whether there's a new version available about once a week. If you don't want TortoiseGit to do this check, set this value to .

VersionCheckPreview

Set this to to make TortoiseGit also check for new preview releases. The default in all stable releases is .

Win8SpellChecker

Set this to to make TortoiseGit use the Windows 8+ spell checker (cf. the section called “Spell checker”). The default is .

Exporting TortoiseGit Settings

If you want to export all your client settings to use on another computer you can do so using the Windows registry editor . Go to the registry key and export it to a reg file. On the other computer, just import that file again (usually, a double click on the reg file will do that).

Remember to save Git's general settings, which you can find in the Git configuration file and/or the folder which both are located in your user profile directory.

Git

Use this page to specify the version control settings that will be applied to the directories of your project that are under Git control.

Path to Git executable

In this field, specify the path to the Git executable file. Type the path or click Browsethe Browse button and specify the path in the dialog that opens.

PyCharm supports Git from the Windows Subsystem for Linux 2 (WSL2), which is available in Windows 10 version 2004.

If Git is not installed on Windows, PyCharm searches for Git in WSL and uses it from there. Also, PyCharm automatically switches to Git from WSL for projects that are opened when you use the \\wsl$ path.

WSL2 support for Git on Windows

Test

Click this button to verify the path to the Git executable file.

Commit

Enable staging area

Enable this option if you are more used to the concept of staging changes for commit instead of using changelists where modified files are staged automatically.

Using the staging area allows you to easily commit changes to the same file separately (including overlapping changes), and see which changes are already staged without switching focus from the editor. For details, see Use the Git staging area to commit changes.

If you enable the staging area, all existing changelists will be deleted.

Warn if CRLF line separators are about to be committed

Select this option to enable smart handling of and line separators. PyCharm will analyze your configuration, warn you if you are about to commit CRLF into the repository, and suggest changing the setting to or depending on your operating system.

This setting is not applied to files where you have set any related Git attributes. In this case, PyCharm assumes that you clearly understand what you are doing and excludes such files from analysis.

If this option is deselected, you will have to fix issues with line endings manually using the Difference Viewer dialog.

Warn when committing in detached HEAD or during rebase

Select this option if you want PyCharm to display a warning when a commit is performed from a detached head or on rebase, as this may cause issues and code loss.

Add the 'cherry-picked from <hash>' suffix when picking commits pushed to protected branches

Select this option if you want to keep a reference to the original commit when cherry-picking a commit from a protected branch. By default, no suffix is added when cherry-picking a change.

Configure GPG Key

Click to configure GPG Key for signing your commits or to select an existing key. See Sign commits with GPG keys for details.

Push

Auto-update if push of the current branch was rejected

Select this checkbox if you want the current branch to be updated automatically if the operation from the current branch to its tracked branch is rejected.

If this option is deselected, PyCharm will display the Push Rejected dialog when pushing a branch is rejected because your local repository and the remote storage are not synchronized.

Note the following:

  • If you have never seen the Push Rejected dialog before and you are enabling the checkbox initially, PyCharm will update the conflicting local branch silently by means of the operation.

  • If you have already encountered the Push Rejected dialog and selected the Remember the update method choice... option, PyCharm saves your last choice or and will apply it to update the conflicting local branch silently.

    Accordingly, to change the "remembered" setting, clear the checkbox, access the Push Rejected dialog, select the Auto-update if push ... rejected option, and invoke another update strategy.

Show Push dialog for Commit and Push

Select this option if you want the Push dialog to be displayed after you've clicked Commit and Push in the Commit Changes dialog. Otherwise, your changes will be pushed automatically to the affected repository.

Show Push dialog only when committing to protected branches

Select this option if you only want to show the Push Changes dialog if you are pushing to a protected branch when you've clicked Commit and Push in the Commit Changes dialog. Otherwise, your changes will be pushed automatically to the affected repository.

Protected branches

If you want to disable the ability to force push changes for certain branches, list them here (this is a team-shared parameter that is stored in .idea/vcs.xml).

You can list several branches separated by a semicolon, or supply branch patterns as the input is treated as a list of regular expressions.

Load branch protection rules from GitHub

Select this option if you want to add GitHub protection rules to PyCharm and sync them on every fetch.

Update

Update method

Use this list to choose the strategy to synchronize your local repository with the remote storage. The selected method will be used when the operation is rejected (if the Auto-updated if push of the current branch was rejected option is enabled), or when you invoke the Update Project operation. The following options are available:

  • Merge: select this option to perform merge during the update. This is equivalent to running and then , or .

  • Rebase: select this option to perform rebase during the update. This is equivalent to running and then , or (all local commits will be put on top of the updated upstream head).

Clean working tree using

Select how you want uncommitted changes to be treated when you perform a project update:

  • Stash: local changes will be saved to a git stash. This is useful if you need to apply patches with stashed changes outside PyCharm, as they are generated by Git itself.

  • Shelve: PyCharm will put local changes to a shelf. Shelving is done by PyCharm, and patches generated from shelved changes are normally applied inside PyCharm.

Filter Update Project information by paths

If you don't want to get information on all changes to a project in the Update Info tab when you perform an update, you can filter the list by specific paths.

Explicitly check for incoming commits on remotes

If this option is enabled, PyCharm will check if there are pending incoming commits that have not been fetched to your local repository, and will mark such branches in the Branches popup.

Select how you want PyCharm to query the remote to check for incoming commits:

  • Auto: PyCharm will check for updates in the background if HTTP or Git protocol is used to access the remote. If SSH is used, this check will not be performed so that external authentication applications don't popup unexpectedly.

  • Always: PyCharm will check for updates in the background even if SSH is used to access the remote.

  • Never: PyCharm will not query the remote for incoming commits, and a warning will be displayed in the Branches popup, allowing you to run the check manually.

Use credential helper

Select this option if you don't want to override credential helpers, which is the default behavior. You will be able to authenticate using a credential helper in the Git login dialog.

Last modified: 21 July 2022

Github for Windows unable to locate Git on my system when opening the command prompt

I have Windows 10 (German) and installed Git for Windows 2.13.2 (64 bit) at "C:\Program Files\Git".

I installed Github for Windows 0.6.2 (64 bit), the desktop version.

I can pull changes from my git repositories on Github just fine.

However, when clicking on menu Repository/Open command prompt an error message shows up saying that Github for Windows was unable to locate Git on my system.

enter image description here

I don't want to open the command prompt without Git nor do I need to install Git because I already have. Nowhere in the settings of Github for Windows I can tell it where to find Git. Adding "C:\Program Files\Git" to the Windows PATH has no effect.

How can I make Github for Windows open the Git bash?

asked Jul 9, 2017 at 12:18

user avatar
TrilarionTrilarion

15511 silver badge1111 bronze badges

Unable to find git executable in PATH; please install Git for Windows before retrying. #2617

@Isaac-Tait Editing environment variables manually in this case isn't dangerous, but it's misleading. The Git for Windows installer will have added these environment variables for you error could not find git path it's a part of its installation process. If error could not find git path also add these entries manually, they might end up duplicated in your PATH or continue to linger around after you've chosen to uninstall Git for Windows (which should ordinarily cleanup environment variables added by the installer).

In summary: nothing wrong with you personally editing environment variables on your own Windows machine, but I don't want to be circulated online as a solution to this problem because I don't want people to be repeating these manual steps. The solution to every problem so far brought up in this thread is to install Git for Windows using the official installer (or using a package manager like Scoop), not to edit environment variables manually, since the latter can be error-prone.

Github for Windows unable to locate Git on my system when opening the command prompt

I have Windows 10 (German) and installed Git for Windows 2.13.2 (64 bit) at "C:\Program Files\Git".

I installed Github for Windows 0.6.2 (64 bit), the desktop version.

I can pull changes from my git repositories on Github just fine.

However, when clicking on menu Repository/Open command prompt an error message shows up saying that Github for Windows was unable to locate Git on my system.

enter image description here

I don't want to open the command prompt error crweating bitmap Git nor do I need to install Git because I already have. Nowhere in the settings of Github for Windows I can tell it where to find Git. Adding "C:\Program Files\Git" to the Windows PATH has no effect.

How can I make Github for Windows open the Git bash?

asked Jul 9, 2017 at 12:18

user avatar
TrilarionTrilarion

15511 silver badge1111 bronze badges

Git

Use this page to specify the version control settings that will be applied to the directories of your project that are under Git control.

Path to Git executable

In this field, specify the path to the Git executable file. Type the path or click Browsethe Browse button and specify the path in the dialog that opens.

PyCharm supports Git from the Windows Subsystem for Linux 2 (WSL2), which is available in Windows 10 version 2004.

If Git is not installed on Error could not find git path, PyCharm searches for Git in WSL and uses it from there. Also, PyCharm automatically switches to Git from WSL for projects that are opened when you use the \\wsl$ path.

WSL2 support for Git on Windows

Test

Click this button to verify the path to the Git executable file.

Commit

Enable staging area

Enable this option if you are more used to the concept of staging changes for commit instead of using changelists where error could not find git path files are staged automatically.

Using the staging area allows you to easily commit changes to the same file separately (including overlapping changes), and see which changes are already staged without switching focus from the editor. For details, see Use the Git staging area to commit changes.

If you enable the staging area, all existing changelists will be deleted.

Warn if CRLF line separators are about to be committed

Select this option to enable smart handling of and line separators. PyCharm will analyze your configuration, error could not find git path, warn you if you are about to commit CRLF into the repository, and suggest changing the setting to or depending on your operating system.

This setting is not applied to files where you have set any related Git attributes. In this case, PyCharm assumes that you clearly understand what you are doing and excludes such files from analysis.

If this option is deselected, you will have to fix issues with line endings manually using the Difference Viewer dialog.

Warn when committing in detached HEAD or during rebase

Select this option if you want PyCharm to display a warning when a commit is performed from a detached head or on rebase, as this may cause issues and code loss.

Add the 'cherry-picked from <hash>' suffix when picking commits pushed to protected branches

Select this option if you want to keep a reference to the original commit when error could not find git path a commit from a protected branch. By default, no suffix is added when cherry-picking a change.

Configure GPG Key

Click to configure GPG Key for signing your commits or to select an existing key. See Sign commits with GPG keys for details.

Push

Auto-update if push of the current branch was rejected

Select this checkbox if you want the current branch to be updated automatically if the operation from the current branch to its tracked branch is rejected.

If this option is deselected, PyCharm will display the Push Rejected dialog when pushing a branch is rejected because your local repository and the remote storage are not synchronized.

Note the following:

  • If you have never seen the Push Rejected dialog before and you are enabling the checkbox initially, PyCharm will update the conflicting local branch silently by means of the operation.

  • If you have already encountered the Push Rejected dialog and selected the Remember the update method choice. option, PyCharm saves your last choice or and will apply it to update the conflicting local branch silently.

    Accordingly, to change the "remembered" setting, clear the checkbox, access the Push Rejected dialog, select the Auto-update if push . rejected option, and invoke another update strategy.

Show Push dialog for Commit and Push

Select this option if you want the Push dialog to be displayed after you've clicked Commit and Push in the Commit Changes dialog. Otherwise, your changes will be pushed automatically to the affected repository.

Show Push dialog only when committing to protected branches

Select this option if you only want to show the Push Changes dialog if you are pushing to a protected branch when you've clicked Commit and Push in the Commit Changes dialog. Otherwise, your changes will be pushed automatically to the affected repository.

Protected branches

If you want to disable the ability to force push changes for certain branches, list them here (this is a team-shared parameter that is stored in .idea/vcs.xml).

You can list several branches separated by a semicolon, or supply branch patterns as the input is treated as a list of regular error could not find git path branch protection rules from GitHub

Select this option if you want to add GitHub protection rules to PyCharm and sync them on every fetch.

Update

Update method

Use this list to choose the strategy to synchronize your local repository with the remote storage. The selected method will be used when the operation is rejected (if the Auto-updated if push of the current branch was rejected option is enabled), or when you invoke the Update Project operation. The following options are available:

  • Merge: select this option to perform merge during the update. This is equivalent to running and thenor .

  • Rebase: select this option to perform rebase during the update. This is equivalent to running and thenor (all local commits will be put on top of the updated upstream head).

Clean working tree using

Select how you want uncommitted changes to be treated when you perform a project update:

  • Stash: local changes will be saved to a git stash. This is useful if you need to apply patches with stashed changes outside PyCharm, as they are generated by Git itself.

  • Shelve: PyCharm will put local changes to a shelf, error could not find git path. Shelving is done by PyCharm, and patches generated from shelved changes are normally applied inside PyCharm.

Filter Update Project information by paths

If you don't want to get information on all changes to a project in the Update Info tab when you perform an update, you can filter the list by specific paths.

Explicitly check for incoming commits on remotes

If this option is enabled, PyCharm will check if there are pending incoming commits that have not been fetched to your local repository, and will mark such branches in the Branches popup.

Select how you want PyCharm to query the remote to check for incoming commits:

  • Auto: PyCharm will check for updates in the background if HTTP or Git protocol is used to access the remote. If SSH is used, this check will not be performed so that external authentication applications don't popup unexpectedly.

  • Always: PyCharm will check for updates in the background even if SSH is used to access the remote.

  • Never: PyCharm will not query the remote for incoming commits, and a warning will be displayed in the Branches popup, allowing you to run the check manually.

Use credential helper

Select this option if you don't want to override credential helpers, which is the default behavior. You will be able to authenticate using a credential helper in the Git login dialog.

Last modified: 21 July 2022

When you install msysgit, you are asked in one of the dialogs how your PATH should be modified.

  1. Use Git Bash Only
  2. Run Git from the Windows Command Prompt
  3. Run Git and included Unix tools from the Windows Command Prompt

If you select option 2. (which I guess most users will pick, as option 3. has a scary warning), error could not find git path, the directory will be added to the PATH.
If you pick option 3. the directory will also be added.

Now if you run "git --version" from ipad 2 restore error 3194 commandline, it will runwhich will call .
I guess Stash tries to run to determine the installed git version.
If you've installed msysgit with option 3. you're fine, as is in your path.
Did you select option 2. you're error could not find git path of luck as that directory as not added to your path.

The workaround for the user is to either run the msysgit installer again and select option 3. to have your PATH properly set, or edit your PATH manually.

If Stash is indeed callingthis problem will be solved if Stash calls instead.

Beanstalk Guides

Setting up Git can be tricky on Windows compared to Linux or Mac, but if you follow the steps in this guide, error could not find git path, you should have no problems using Git on Windows. We’ve done the hard work and chosen between the multiple options error could not find git path key steps to help make things easier for you. This guide will take you through the steps to install and configure Git and connect it to remote repositories to clone, push, and pull. If you don’t have one already, create a Beanstalk account.

Choosing a Git distribution

There are two competing Git packages for Windows: a Cygwin-based Git and a version called msysGit. We will describe how to install error could not find git path msysGit package. We recommend installing msysGit because we’ve found it’s easier to work with than the Cygwin based installation.

Installing Git

Once you have downloaded the msysGit executable, double click on it to start the icq system error code 10053 wizard. Leave the default directory options. When you get to the “Adjusting your Path environment” setting, select the “Run Git from the Windows Command Prompt” option. Choosing this option will make it easy for you to run Git commands from the Windows Command Prompt (command line) if you choose. Command Prompt is a simple tool, where you can run commands, switch through folders, manage files and it can be ran by selecting in menu, and executing command.

Git Bash

You will notice that for the rest of this article we will use Git Bash for running Git commands. The Git Bash tool works in the same way as the default Windows’ Command Prompt, but has some special features. With Git Bash you’ll be able to use a number error could not find git path UNIX command line tools along with access to Git, and we recommend it since it’s often simpler to use than the Windows Command Prompt.

You can run it by right clicking your mouse on error could not find git path desktop, and selecting from pop up window.

When you reach the step “Configuring the line ending conversions”, make sure to leave the option “Checkout Windows-style, commit Unix-style line endings” selected. This option makes sure that Git converts LF to CRLF when checking out text files. When committing text files, CRLF will also be socket error 3426 to LF. This is a compatibility measure to protect newlines in text files, allowing you to easily work with text files on Windows and on Unix-style platforms.

Important note: The most common problems when setting up Git on Windows are related to SSH keys, error could not find git path. Git uses SSH keys to securely access your repositories, and in Windows SSH keys are often searched on the wrong path when you try to use Git.

If you use an older version of msysGit, you may encounter a step called “Choosing the SSH executables”. If you encounter that dialog, we recommend that you choose the “Use OpenSSH” option.

After you have successfully installed Git on Windows, you’ll need to provide secure communication with your Git repositories by creating and installing SSH keys.

Installing SSH keys on Windows

To access constant sintax error Git repositories you will need to create and install SSH keys. You can do this in two ways:

  • by using OpenSSH (generating SSH keys with which comes with Git)
  • by using PuTTY (free Telnet and SSH client)

OpenSSH and PuTTY are free implementations of Telnet and SSH for Windows. They encrypt all traffic and provide secure communication with your remote Git repositories by using SSH keys.

We recommend OpenSSH over PuTTY, and it’s installed with your Git copy. PuTTY is recommended only for advanced users who are already familiar with how Git with SSH keys work.

Using OpenSSH and generating SSH keys with ssh-keygen

To communicate with the remote Git repository in your Beanstalk account from your Windows computer, you will need to generate an SSH key pair for that computer. This process requires only a few steps, but you do first need to install msysGit adobe illustrator runtime error the full installer as described above.

Generating a key pair

To do this you need to run Git Bash, which can be found in your menu. Run the command:

It will ask for location and pass phrase. Accept the default location (usually or ) by pressing. After that, make sure to set a strong pass phrase for the key.

Now that the keys are generated, open the file (found in the default location from the previous step) with a text editor. The contents of this file is your new public key. If you copy it to your clipboard, you can add it to your Beanstalk profile (under the section).

Your SSH public key should look something like this:

In your Beanstalk account, SSH key would look like this:

SSH Key Details in Beanstalk

After you have setup the SSH key on Beanstalk, you should be able to check a connection and then push or pull with your remote Git repository. In case you have trouble with SSH keys check path in your Windows operating system. Some other software can change or environment variable to point to different location, instead of your real home (Documents and Settings) directory.

Checking your connection

Before trying to access your Beanstalk repository, check if the connection to your remote repository works. In order to do that, run Git Bash, and enter this command, replacing with your account name:

In this case, this is the URL to access Git on your Beanstalk account. If you are using another version control hosting service, the URL would be provided by them.

When authenticating or later when trying to connect to Git repository most likely you will encounter a message that looks like this:

You can type and presswhich will add your account’s hostname to a file. This step won’t need to be repeated later, unless your public key or your account names changes.

If you were authenticated correctly, you will see a message similar to this one:

You can now continue to configure your local Git profile.

In case you have installed TortoiseGIT

GIT_SSH Variable

If you have ever installed TortoiseGit on the computer you’re setting up your keys on, you may encounter problems. TortiseGit creates an environment variable that configures Plink 12560 tns protocol adapter error your SSH keystore, which may conflict when you try to use Git and SSH. No matter how you change your config or uninstall TortoiseGit, that environment variable persists and until you delete it, Git will not look to your regular directory to find the proper key.

In our case environment variable looked like this:. Environment variables can be found here:

  • Windows XP:
  • Windows 7:

Having problems connecting to your Git repository on Windows 7?

Our users have reported problems when generating SSH keys on Windows 7 systems. If that happens for you, try generating your SSH keys on Windows XP if possible. After generating the private and public keys (following the steps to generate keys are provided above in the Generating a key pair chapter), copy the files to default SSH keys location in Windows 7 (usually or ).

Alternative to OpenSSH — using PuTTY to access your Git repository

Installing Git and using PuTTY to connect to your Git repository can be troublesome, so we recommend that you use the OpenSSH method which we described in the steps above. Using OpenSSH is simple and straightforward, but if OpenSSH is not an option, or for some other reason you prefer to use PuTTY to connect to your repositories, here is a step by step guide on how to do so.

Like OpenSSH, you will generate Delphi removedir error 145 keys and use them to communicate with your remote Git repositories, only now you will use PuTTY’s tools for generating, storing, and using the keys.

Installing PuTTY

You can download the PuTTY installation package and run it. The latest installation package at the moment of writing this article is putty-0.60-installer.exe which can be found under “A Windows installer for everything except PuTTYtel” heading.

Install PuTTY to the default recommended location, typically. Once installed, navigate to the installation folder where you will find:

  •  – a command-line interface to the PuTTY back ends
  •  – an RSA and DSA key generation utility
  •  – an SSH authentication agent for PuTTY, PSCP and Plink, in which we will store keys
  •  – the Telnet and SSH client

You will also find some other files, but for this guide you only need to know about plink, puttygen, pageant and putty.

Adding GIT_SSH variable to environment

After you have installed PuTTY package, you’ll need to add a variable to your environment variables which should point to the plink.exe file (including its entire path). Accepting our defaults from cmaterial precachevars error loading, this will likely be:

Environment variables can be found and created/edited here, depending on your version of Windows:

  • Windows XP:
  • Windows 7:

Generating SSH key with puttygen

PuTTY Key Generator

After setting up the environment variable, you need to generate and save SSH keys with puttygen. Run puttygen.exe, error could not find git path, which will allow you to generate a SSH-2 RSA public/private keypair. Once generated, save the public and private keys to a folder of your preference, just make sure to note the folder where the keys are shared. Easiest way to remember which is the private/public key is to name them and so you can distinguish them later.

Before leaving puttygen, copy the public key to your clipboard and paste it into your version control hosting account (in Beanstalk, under the section).

Please note that when you generate a key with puttygen, the public key that you copy from puttygen and the public key you save to a file for later use are not in the same format. You can see on the picture below that the public key was saved with new lines and without the “ssh-rsa” keyword. In order to copy and paste the public key to Beanstalk, you need to copy it in the same format as it was when it was generated by puttygen. That format should be: “ssh-rsa keycodegenerated”. All you need to do is modify your key in an editor like Notepad, and then add it to Beanstalk.

Puttygen Public SSH Key Details

Adding your private key to pageant

Pageant Key List

After you have generated the SSH keypair, error could not find git path, you need to add the SSH private key to pageant, PuTTY’s key management tool. First, run pageant, which can be found in the directory where you have installed PuTTY package (remember, by default: ). You will see a small icon in your system tray (see the screenshot to the right), which indicates pageant is started. Click on the icon and in pageant window click “Add Keys”. Add the private key that was generated by puttygen in error could not find git path previous step. The private key has extension .ppk, that is the easiest way to distinguish it from the public key you have created.

After you add the SSH key, you should see it error code 317 pageant key list.

Checking your connection

Once you have finished setting up PuTTY, all you need to do is check if the connection to your remote hosted Git repository works if you installed Git.

If you still haven’t installed Git download the msysGit executable, double click on it and the installation wizard should start. Leave the default directory options. When you get to the “Adjusting your Path environment” setting, select the “Use Git Bash only” option. Error could not find git path this option will help you avoid path conflicts.

After you have installed Git run Git Bash and error could not find git path to the directory where you have installed PuTTY and try to access your repository by typing this:

If you are not authenticated correctly, a message like the following screenshot will pop up:

Putty Error

If you are authenticated correctly, a new window will pop up with message like this:

Pop up window will close shortly after authentication is finished, which means authentication was successful and you should be able to manage your Git repositories from now on.

Setting up Git profile

After you have authenticated correctly by installing Git and setting up SSH keys, before you start using your Git repositories, you should setup your Git profile by typing following after you run Git bash in command line:

In case you are using Beanstalk for version control, it would be best if your first name, last name and email address match to the ones you use in your account to avoid any conflicts.

Summary

In order to be able to use your repository you need to:

  • Install Git
  • Generate SSH keys with PuTTY or ssh-keygen
  • Put keys in correct place (in pageant for PuTTY, in correct folder for OpenSSH)
  • Check if connection to the Git repository is working
  • Setup your Git profile

While setting up Git the most common mistakes include mismatched private and public SSH keys or the user doesn’t have permission to access the repository. If you run into any issues connecting to Beanstalk, error could not find git path hesitate to contact us using the links below.

Now what?

Now that you have Git properly installed and configured, you can use a client of your choice. Whether you choose a terminal or a GUI, it is a good idea to learn the basic concepts and commands for versioning your files before. Here’s some recommended reading to get you started:

Igor BalošIgor Baloš is a QA engineer from Novi Sad, Serbia.

Back to Guides

A number controlling the amount of output shown by the recursive merge strategy. Overrides merge.verbosity. See git-merge[1]

This environment variable overrides. If it is set to an empty string or to the value "cat", Git will not launch a pager. See also the option in git-config[1].

A number controlling how many seconds to delay before showing optional progress indicators. Defaults to 2.

This environment variable overrides and. It is used by several Git commands when, on interactive mode, an editor is to be launched. See also git-var[1] and the option in git-config[1].

This environment variable overrides the configured Git editor when editing the todo list of an interactive rebase. See also git-rebase[1] and the option in git-config[1].

If either of these environment variables is set then git fetch and git push will use the specified command instead of ssh when they need to connect to a remote system. The command-line parameters passed to the configured command are determined by the ssh variant. See option in git-config[1] for details.

takes precedence overand is interpreted by the shell, which allows additional arguments to be included. on the other hand must be just the path to a program (which can be a wrapper shell script, if additional arguments are needed).

Usually it is easier to configure any desired options through your personal file. Please consult your ssh documentation for further details.

If this environment variable is set, it overrides Git’s autodetection whether // refer to OpenSSH, plink or tortoiseplink. This variable overrides the config setting that serves the same purpose.

If this environment variable is set, then Git commands which need to acquire passwords or passphrases (e.g. for HTTP or IMAP authentication) will call this program with a suitable prompt as command-line argument and read the password from its STDOUT. See also the option in git-config[1].

If this environment variable is set togit will not prompt on the terminal (e.g., when asking for HTTP authentication).

Take the configuration from the given files instead from global or system-level configuration files. If is set, the system config file defined at build time (usually ) error could not find git path not be read. Likewise, if is set, neither nor will be read. Can be set to to skip reading configuration files of the respective level.

Whether to skip reading settings from the system-wide file. This environment variable can be used along with and to create a predictable environment for a picky script, or you can set it temporarily to avoid using a buggy file while waiting for someone with sufficient permissions to fix it.

If this environment variable is set to "1", then commands such as git blame (in incremental mode), git rev-list, git log, git check-attr and git scsi controller configuration error 02 will force a flush of the output stream after each record have been flushed. If this variable is set to "0", the output of these commands will be done using completely buffered I/O. If this environment variable is not set, Git will choose buffered or record-oriented flushing based on whether stdout appears to be redirected to a file or not.

Enables general trace messages, e.g. alias expansion, built-in command execution and external command execution.

If this variable is set to "1", "2" or "true" (comparison is case insensitive), error could not find git path, trace messages will be printed to stderr.

If the variable is set to an integer value greater than 2 and lower than 10 (strictly) then Git will interpret this value as an open file descriptor and will try to write the trace messages into this file descriptor.

Alternatively, if the variable is set to an absolute path (starting with a / character), Git will interpret this as a file path and will try to append the trace messages to it.

Unsetting the variable, or setting it to empty, error could not find git path, "0" or "false" (case insensitive) disables trace messages.

Enables trace messages for the filesystem monitor extension. See for available trace output options.

Enables trace messages for all accesses to any packs. For each access, the pack file name and an offset in the pack is recorded. This may be helpful for troubleshooting some pack-related performance problems. See for available trace output options.

Enables trace messages for all packets coming in or out of a given program. This can help with debugging object negotiation or other protocol issues. Tracing is turned off at a packet starting with "PACK" (but see below). See for available trace output options.

Enables tracing of packfiles sent or received by a given program. Unlike other trace output, this trace is verbatim: no headers, and no quoting of binary data. You almost certainly want to direct into a file (e.g., ) rather than displaying it on the terminal or mixing it with other trace output.

Note that this is currently only implemented for the client side of clones and fetches.

Enables performance related trace messages, e.g. total execution time of each Git command. See for available trace output options.

Enables trace messages for operations on the ref database. See for available trace output options.

Enables trace messages printing the .git, working tree and current working directory after Git has completed its setup phase. See for available trace output options.

Enables trace messages that can help debugging fetching / cloning of shallow repositories, error could not find git path. See for available trace output options.

Enables a curl full trace dump of all incoming and outgoing data, including descriptive information, of the git transport protocol. This is similar to doing curl on the command line. See for available trace output options.

When a curl trace is enabled (see above), do not dump data (that is, only dump info lines and headers).

Enables more detailed trace messages from the "trace2" library. Output from is a simple text-based format for human readability.

If this variable is set to "1", error could not find git path, "2" or "true" (comparison is case insensitive), trace messages will be printed to stderr.

If the variable is set to an integer value greater than 2 and lower than 10 (strictly) then Git will interpret this value as an open file descriptor and will try to write the trace messages into this file descriptor.

Alternatively, if the variable is set to an absolute path (starting with a / character), Git will interpret this as a file path and will try to append the trace messages to it. If the path already exists and is a directory, the trace messages will be written to files (one per process) in that directory, error could not find git path, named according to the last component of the SID and an optional counter (to avoid filename collisions).

In addition, if the variable is set toGit will try to open the path as a Unix Domain Socket. The socket type can be either or .

Unsetting the variable, or setting it to empty, "0" or "false" (case insensitive) disables trace messages.

This setting writes a JSON-based format that is suited for machine interpretation. See for available trace output options and Trace2 documentation for full details.

In addition to the text-based messages available inthis setting writes a column-based format for understanding nesting regions. See for available trace output options and Trace2 documentation error could not find git path full details.

By default, when tracing is activated, Git redacts the values of cookies, the "Authorization:" header, the "Proxy-Authorization:" header and packfile URIs. Set this variable to to prevent this redaction.

Setting this variable to will cause Git to treat all pathspecs literally, rather than as glob patterns. For example, running will search for commits that touch the pathnot any paths that the glob matches. You might want this if you are feeding literal paths to Git (e.g., paths previously given to you by diff output, etc).

Setting this variable to will cause Git to treat all pathspecs as glob patterns (aka "glob" magic).

Setting this variable to will cause Git to treat all pathspecs as literal (aka "literal" magic).

Setting this variable to will cause Git to treat all pathspecs as case-insensitive.

When a ref is updated, reflog entries are created to keep track of the reason why the ref was updated (which error could not find git path typically the name of the high-level command that updated the ref), in addition to the old and new values of the ref. A scripted Porcelain command can use set_reflog_action helper function in to set its name to this variable when it is invoked as the top level command by the end user, to be recorded in the body of the reflog.

If set toignore broken or badly named refs when iterating over lists of refs. Normally Git will try to include any such refs, which may cause some operations to fail. This is usually preferable, as potentially destructive operations (e.g., git-prune[1]) are better off aborting rather than ignoring broken refs (and thus considering the history they point to as not worth saving). The default value is (i.e., be paranoid about detecting and aborting all operations). You should not normally need to set this tobut it may be useful when trying to salvage data from a corrupted repository.

If set to a colon-separated list of protocols, behave as if is set toand each of the listed protocols has set to (overriding any existing configuration). See the description of in git-config[1] for more details.

Set to 0 to prevent protocols used by fetch/push/clone which are configured to the state. This is useful to restrict recursive submodule initialization from an untrusted repository or for programs which feed potentially-untrusted URLS to git commands. See git-config[1] for more details.

For internal use only. Used in handshaking the wire protocol. Contains a colon : separated list of keys with optional values key[=value]. Presence of unknown keys and values must be ignored.

Note that servers may need to be configured to allow this variable to pass over some transports, error could not find git path. It will be propagated automatically when accessing local repositories (i.e., or a filesystem path), error xntpd is way too large well as over the protocol. For git-over-http, it should work automatically in most configurations, but see the discussion in git-http-backend[1]. For git-over-ssh, the ssh server may need to be configured to allow clients to pass this variable (e.g., by using with OpenSSH).

This configuration is optional. If the variable is not propagated, then clients will fall back to the original "v0" protocol (but may miss out on some performance improvements or features). This variable currently only affects clones and fetches; it is not yet used for pushes (but may be in the future).

If set toGit will complete any requested operation without performing any optional sub-operations that require taking a lock. For example, this will prevent from refreshing the index as a side effect. This is useful for processes running in the background which do not want to cause lock contention with other operations on the repository. Defaults to .

Windows-only: allow redirecting the standard input/output/error handles to paths specified by the environment variables. This is particularly useful in multi-threaded applications where the canonical way to pass standard handles via is not an option because it would require the handles to be l2 error code=610 inheritable (and consequently every spawned process would inherit them, possibly blocking regular Git operations). The primary intended use case is to use named pipes for communication (e.g. ).

Two special values are supported: will simply close the corresponding standard handle, and if isstandard error will be redirected to the same handle as standard internal server error 500 modx (deprecated)

If set toprint an ellipsis following an (abbreviated) SHA-1 value. This affects indications of detached HEADs (git-checkout[1]) and the raw diff output (git-diff[1]). Printing an ellipsis in the cases mentioned is pioneer error 60 longer considered adequate and support for it is likely to be removed in the foreseeable future (along with the variable).

0 Comments

Leave a Comment