What Is the Best Git Config Set Up When You Are Using Linux and Windows

What is the best git config set up when you are using Linux and Windows?

As detailled in Git on Windows (msysgit) - Unix or DOS line termination, I would use:

git config --system core.autocrlf false

That would avoid any automatic eol transformation (See "Git on Windows: What do the crlf settings mean?" for the exact meaning of this option value).

You can leave it to true, as explained in git replacing LF with CRLF, but I prefer setting core.eol + some gitattribute files in order to fine tune some of the files I want eol changes on.

See this answer for more details.

Best practices for cross platform git config?

I have reviewed that kind of config setting (crlf) extensively in the question:

distributing git configuration with the code.

The conclusion was:

checkout/checking .gitattributes files
list all types which explicitly need that kind of conversion.

For instance:


*.java +crlf
*.txt +crlf
...

avoid doing any kind of conversion of type of files which don't need it, because of the various side-effect of such a conversion on merges, git status, shell environment and svn import (see "distributing git configuration with the code" for links and references).
avoid any crlf conversion altogether if you can.

Now, regarding the specific issue of per-platform settings, branch is not always the right tool, especially for non-program related data (i.e; those settings are not related to what you are developing, only to the VCS storing the history of your development)

As stated in the question Git: How to maintain two branches of a project and merge only shared data?:

your life will be vastly simpler if you put the system-dependent code in different directories and deal with the cross-platform dependencies in the build system (Makefiles or whatever you use).

In this case, while branches could be use for system-dependent code, I would recommend directory for support tools system-dependent settings, with a script able to build the appropriate .gitattributes file to apply the right setting depending on the repo deployment platform.

How can I help git for Windows better handle a repository sitting on a Linux Samba share?

Ok, after digging some more, I've found the issue was due to different file mode flags because of my Samba configuration. I was able to fix things by disabling the fileMode option at the repo level:

git config --unset core.fileMode

And setting it globally on the Windows box:

git config --global core.fileMode true

Platform-specific git configuration files

You could rename your current .gitconfig file to something like .gitconfig-common, and change the platform-specific files to include it (instead of the other way around). Then, on each machine where you work, create a .gitconfig file outside of Dropbox that does nothing but include the appropriate platform-specific file in your Dropbox.

So on Windows, for example, you'd have .gitconfig include .gitconfig-windows, which includes .gitconfig-common. The .gitconfig file contains nothing but a platform-specific include directive so there's no need to synchronize it with Dropbox.

How can I set up an editor to work with Git on Windows?

Update September 2015 (6 years later)

The last release of git-for-Windows (2.5.3) now includes:

By configuring git config core.editor notepad, users can now use notepad.exe as their default editor.

Configuring git config format.commitMessageColumns 72 will be picked up by the notepad wrapper and line-wrap the commit message after the user edits it.

See commit 69b301b by Johannes Schindelin (dscho).

And Git 2.16 (Q1 2018) will show a message to tell the user that it is waiting for the user to finish editing when spawning an editor, in case the editor
opens to a hidden window or somewhere obscure and the user gets
lost.

See commit abfb04d (07 Dec 2017), and commit a64f213 (29 Nov 2017) by Lars Schneider (larsxschneider).

Helped-by: Junio C Hamano (gitster).

^{(Merged by Junio C Hamano -- gitster -- in commit 0c69a13, 19 Dec 2017)}

launch_editor(): indicate that Git waits for user input

When a graphical GIT_EDITOR is spawned by a Git command that opens
and waits for user input (e.g. "git rebase -i"), then the editor window
might be obscured by other windows.

The user might be left staring at
the original Git terminal window without even realizing that s/he needs
to interact with another window before Git can proceed. To this user Git
appears hanging.

Print a message that Git is waiting for editor input in the original
terminal and get rid of it when the editor returns, if the terminal
supports erasing the last line

Original answer

I just tested it with git version 1.6.2.msysgit.0.186.gf7512 and Notepad++5.3.1

I prefer to not have to set an EDITOR variable, so I tried:

git config --global core.editor "\"c:\Program Files\Notepad++\notepad++.exe\""
# or
git config --global core.editor "\"c:\Program Files\Notepad++\notepad++.exe\" %*"

That always gives:

C:\prog\git>git config --global --edit
"c:\Program Files\Notepad++\notepad++.exe" %*: c:\Program Files\Notepad++\notepad++.exe: command not found
error: There was a problem with the editor '"c:\Program Files\Notepad++\notepad++.exe" %*'.

If I define a npp.bat including:

"c:\Program Files\Notepad++\notepad++.exe" %*

and I type:

C:\prog\git>git config --global core.editor C:\prog\git\npp.bat

It just works from the DOS session, but not from the git shell.

(not that with the core.editor configuration mechanism, a script with "start /WAIT..." in it would not work, but only open a new DOS window)

Bennett's answer mentions the possibility to avoid adding a script, but to reference directly the program itself between simple quotes. Note the direction of the slashes! Use / NOT \ to separate folders in the path name!

git config --global core.editor \
"'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"

Or if you are in a 64 bit system:

git config --global core.editor \
"'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"

But I prefer using a script (see below): that way I can play with different paths or different options without having to register again a git config.

The actual solution (with a script) was to realize that:

what you refer to in the config file is actually a shell (/bin/sh) script, not a DOS script.

So what does work is:

C:\prog\git>git config --global core.editor C:/prog/git/npp.bat

with C:/prog/git/npp.bat:

#!/bin/sh
"c:/Program Files/Notepad++/notepad++.exe" -multiInst "$*"

#!/bin/sh
"c:/Program Files/Notepad++/notepad++.exe" -multiInst -notabbar -nosession -noPlugin "$*"

With that setting, I can do 'git config --global --edit' from DOS or Git Shell, or I can do 'git rebase -i ...' from DOS or Git Shell.

Bot commands will trigger a new instance of notepad++ (hence the -multiInst' option), and wait for that instance to be closed before going on.

Note that I use only '/', not \'. And I installed msysgit using option 2. (Add the git\bin directory to the PATH environment variable, but without overriding some built-in windows tools)

The fact that the notepad++ wrapper is called .bat is not important.

It would be better to name it 'npp.sh' and to put it in the [git]\cmd directory though (or in any directory referenced by your PATH environment variable).

Move git configuration from Windows to Ubuntu

To build upon Hi-Angel's answer:

Under Windows 7

The local Git config is inside the .git directory at the root of your repository/project.
The global Git settings are in C:\Users\<user_name>\.gitconfig.
The SSH keys you generated are in C:\Users\<user_name>\.ssh (at least, this is the standard).

Under Ubuntu/Linux

The local Git config is inside the .git directory at the root of your repository/project (no change and no work here).
The global Git settings are in ~/.gitconfig.
The SSH keys you generated are in ~/.ssh (at least, this is the standard).

Doing the switch

Copy your .gitconfig and .ssh folders from one to the other and you should be good to go.

If you configured some things specific to your OS (such as default editors), you will have to configure those again or reset them after performing the copy, but this cannot be avoided.

Just a note about SSH and security

You may consider it a hassle, but if one of your computers is a laptop, I would recommend configure separate SSH keys. That way, if your laptop ever gets stolen, you can remove the key and this laptop will never be able to mess with your central repository.

It may not seem that important for codes, but if you use SSH for other purposes (like administering your private server), I think it is crucial to be able to select which computers are allowed to connect.

Git on Windows: What do the crlf settings mean?

The three values for autocrlf:

true - when content goes into the repository (is committed), its line endings will be converted to LF, and when content comes out of the repository (is checked out), the line endings be converted to CRLF. This is in general meant for clueless windows users/editors. Given the assumption that an editor (or user) is going to create files with CRLF endings, and will freak out if it sees normal LF endings, but that you want LF endings in the repo, this will hopefully cover you. It's possible for things to go awry, though. There are examples of spurious merge conflicts and reports of modified files in the linked questions.
input - when content goes into the repository, its line endings will be converted to LF, but content is left untouched on the way out. This is basically in the same realm as true, with the assumption that the editors actually can deal with LF endings correctly; you're just guarding against the possibility of accidentally creating a file with CRLF endings.
false - git doesn't deal with line endings at all. It's up to you. This is what a lot of people recommend. With this setting, if a file's line endings are going to be messed with, you'll have to be aware of it, so merge conflicts are a lot less likely (assuming informed users). Educating developers about how to use their editors/IDEs can pretty much take care of the problem. All of the editors I've seen designed for programmers are capable of dealing with this if configured properly.

Note that autocrlf will not affect content which is already in the repository. If you've committed something with CRLF endings previously, they'll stay that way. This is a very good reason to avoid depending on autocrlf; if one user doesn't have it set, they can get content with CRLF endings into the repo, and it'll stick around. A stronger way to force normalization is with the text attribute; setting it to auto for a given path will mark it for end-of-line normalization, assuming git decides the content is text (not binary).

A related option is safecrlf, which is basically just a way to make sure you don't irreversably perform CRLF conversion on a binary file.

I don't have a ton of experience dealing with Windows issues and git, so feedback about implications/pitfalls is certainly welcome.

Is it possible to have different Git configuration for different projects?

The .git/config file in a particular clone of a repository is local to that clone. Any settings placed there will only affect actions for that particular project.

(By default, git config modifies .git/config, not ~/.gitconfig - only with --global does it modify the latter.)

How to change line-ending settings

The normal way to control this is with git config

For example

git config --global core.autocrlf true

For details, scroll down in this link to Pro Git to the section named "core.autocrlf"

If you want to know what file this is saved in, you can run the command:

git config --global --edit

and the git global config file should open in a text editor, and you can see where that file was loaded from.

Getting Git to work with a proxy server - fails with Request timed out

Command to use:

git config --global http.proxy http://proxyuser:proxypwd@proxy.server.com:8080

change proxyuser to your proxy user
change proxypwd to your proxy password
change proxy.server.com to the URL of your proxy server
change 8080 to the proxy port configured on your proxy server

Note that this works for both http and https repos.

If you decide at any time to reset this proxy and work without proxy:

Command to use:

git config --global --unset http.proxy

Finally, to check the currently set proxy:

git config --global --get http.proxy

What Is the Best Git Config Set Up When You Are Using Linux and Windows