Use the default merge tool with git and Mac OS X - macos

I was changing the default merge tool of git, and an error occurred with my configuration, now my git doesn't work.
Is possible come back to the default configuration?
Thanks

In addition to Alan Haggai Alavi's answers, which is inclusive of the following, if you are confident that changing the merge tool was the problem, you can just revert your merge tool changes:
git config --global --unset merge.tool
git config --unset merge.tool

Review Git configuration files:
Global user configuration file: ~/.gitconfig
Repository configuration file: .git/config

Related

Git LFS does not respect level of config files for credential.helper

Running a Git LFS command such as
GIT_TRACE=1 git lfs locks
reveals that the system credential.helper is used, even though it is overwritten by the local config.
Running
git config --system -l
lists 'credential.helper=manager'
whereas
git config --local -l
only lists 'credential.helper=other'
Running the Git LFS locks command with the tracer enabled shows this line
run-command.c:663 trace: run_command: 'git credential-manager get'
Removing the system wide manager with
git config --system --unset credential.helper
fixes the issue and my local helper 'other' is used correctly.
According to the git configuration documentation, each level trumps the previous level, hence Git LFS is not respecting the git standard. Is there any smart way to make this work without unsetting the system wide helper and by that potentially breaking authentication for other repositories?
Actually, Git LFS is doing the right thing here. It uses Git's git credential command and therefore inherits exactly the behavior that Git itself has.
While you are correct that when a Git option takes a single value, more specific configuration files override more general files, in the case of credential.helper, it's possible to specify multiple values. This can be helpful if you have a custom credential helper for one set of sites (e.g., those in one set of domains) and then a regular helper for other sites. All the credential helpers in this case will be asked for credentials until one is found that provides the required credentials.
If you want to override this for just one repository, you can write something like this in .git/config to first clear the existing list (with the empty entry) and then add a new credential helper:
[credential]
helper =
helper = other
This is pretty tricky to set correctly from git config, so I recommend editing the file by hand.

How to change commiter author's name in Xcode

Can I change committer author's name in Xcode?
From Xcode in section Adjust Editor Options in Authors I see TarasChernysh and name of commit. So I'd like to use Taras instead of TarasChernysh. Can you help me?
You can change this with following command, if TarasChernysh is your own git user.name:
git config --global user.name "Taras"
The --global will make sure all of your future commits use this given user.name. If you will only in the certain repository, then leave --global out and the user.name changed only for this repository.

Git 2.13 conditional config on windows

Git version: 2.13.0.windows.1
OS: Windows 7
CLI: Git bash
.gitconfig
[user]
name = Gyandeep Singh
email = private#email.com
[push]
default = current
[core]
autocrlf = input
[includeIf "gitdir: ~/Documents/webstorm/corporate/"]
path = .gitconfig-work
.gitconfig-work
[user]
name = Gyandeep Singh
email = corporate#email.com
Both the config files above sit together in the same directory (home).
What happened: open CLI on a folder (example test) inside corporate folder and then run git config user.email the output is private#email.com.
Expected: Outcome should be corporate#email.com.
Am I doing something wrong or my expectation is not correct? I did follow the git docs.
Solution
You have to run git config --show-origin --get user.email on a git initialized directory. If its not git initialized then the includeIf gitdir functionality will not work.
Its strange but true. I wish it still worked.
Your global C:/Users/<user-name>/.gitconfig should have this includeIf:
[includeIf "gitdir:C:/Users/<user-name>/Documents/webstorm/corporate/"]
path = .gitconfig-work
with having your work Git repos in C:/Users/<user-name>/Documents/webstorm/corporate and the conditional work configuration should be located at C:/Users/<user-name>/.gitconfig-work.
That's at least working for me in Window's cmd and Cmder. A git config --show-origin --get user.email should than show you from where a config value is loaded/resolved.
It also seems like the conditional work configuration is only used when issued from within a Git repository.
C:\Users\<user-name>\Documents\webstorm\corporate
λ git config --show-origin --get user.email
file:C:/Users/<user-name>/.gitconfig foo#oss.com
C:\Users\<user-name>\Documents\webstorm\corporate\some-repo
λ git config --show-origin --get user.email
file:C:/Users/<user-name>/.gitconfig-work foo#company.com
C:\Users\<user-name>\Documents\webstorm\corporate\some-non-repo-dir
λ git config --show-origin --get user.email
file:C:/Users/<user-name>/.gitconfig foo#oss.com
You need to turn off case sensitivity: change "gitdir:" to "gitdir/i:"
[includeIf "gitdir/i:C:/Work/"]
path = .gitconfig-work
[includeIf "gitdir/i:C:/My/Dev/"]
path = .gitconfig-my
from:
https://github.com/Microsoft/vscode/issues/62921#issuecomment-437693020
The accepted answer, while helpful, does not answer the question.
As of this writing, includeIf only works inside a git initialized folder.
So if you cd into "~/Documents/webstorm/corporate/somegitproject" and run the command the output will be as expected:
$ cd ~/Documents/webstorm/corporate/somegitproject
$ git config user.email
corporate#email.com
This is probably a defect against git, since a user would expect this to work similarly in "~/Documents/webstorm/corporate/" as well.
There is a typo here:
[includeIf "gitdir: ~/Documents/webstorm/corporate/"]
path = .gitconfig-work
There should be no space after gitdir::
[includeIf "gitdir:~/Documents/webstorm/corporate/"]
path = .gitconfig-work
Removing it will correct the behavior within an initialized Git repository.
This will show the entire Git configuration and what Git config files it is drawn from:
git config --list --show-origin
CAVEAT: If you run this inside a Git repository it will show values from .gitconfig-work, but it will not if you are within ~/Documents/webstorm/corporate/, but outside a Git repository.
The OP concludes that includeIf functionality does not work in normal non-git directories.
This is provably incorrect for at least the configuration item core.sshCommand. If a conditionally included .gitconfig has a core.sshCommand configured, it is used in git clone operations in normal non-git directories.
It seems that the part that doesn't work properly is the display of conditionally included configuration. Which is quite problematic and interferes with tracking down broken configurations.
I mapped a directory to a drive on a windows machine with subst D: <mapped directory>. If you want to know the path of your repository you can use this command in the repository context:
git rev-parse --show-toplevel
The output was something like this:
<mapped directory>/<name of repository>
So I changed it to:
[includeIf "gitdir:<mapped directory>/"]
path = .gitconfig-work
Now it works for me.

How Can I Configure GitHub Desktop/Windows to Work with a Proxy?

New to working with git in Windows. I downloaded the GitHub Desktop application and can connect my account, but doing pushes/pulls fails because of an unresolved host. Asking around the workplace I got the following suggestion to type this command into the git shell.
git config --global http.proxy http://username:password#proxy.workplace.com:8080
Does this:
Store my password in plain text?
Send my password in plain text?
Doesn't GitHub for Desktop generate and use SSH keys instead (I got an email notification when I first connected my account)? How can I configure GitHub Desktop to work with this proxy?
To directly add a proxy to Github Desktop without using git shell:
Set up/Sign in to your account in Github Desktop(This won't be a problem, proxy only doesn't allow you to Add, create or clone repo)
Close Github Desktop for the time being(to set up proxy).
Go to C:\Users\#yourusername.
There you will find a file named .gitconfig
Open it with any text editor(I have used sublime text 3) and add
[http]
proxy = http://username:password#your.proxy.address:8080
and save.
Now you can add, create and clone repos in Github Desktop.
Note(for TFS users): TFS will return 502 bad gateway error when you use the above proxy configuration. Use hash # to comment out the proxy config in .gitconfig to switch between Git and TFS.
So actually the solution was to type this command into the git shell.
git config --global http.proxy http://<proxy-ip>:<proxy-port>
Try and upgrade to GitHub Desktop 2.4 (March 2020)
Working behind a proxy
With GitHub Desktop 2.4, we automatically handle setup without needing you to configure anything manually—worry no more!
It might work with this:
git config --global http.proxy proxy_address:proxy_port
git config --global https.proxy proxy_address:proxy_port
If username and password are not that much important then use:
git config --global http.proxy username:password#proxy_address:proxy_port
git config --global https.proxy username:password#proxy_address:proxy_port

Git on live Windows Server - Trying to pull from the repo but local files already modified

I have my Git repository hosted at github.com. I would like to push updates and such to github.com and then log into my Windows server and do a git pull to get my changes (that are verified to work on my local machine. Ideally I should have another server setup as my local machine settings are different from the live server. But I'm cheap.).
It seems like whenever I try to do a git pull on the server, the files seem to get modified somehow since the last pull. And so I am unable to get the update as git says I need to commit my local (Windows server) changes.
How can I use git like I want to? Or is there a better way?
Is it possible you change the git core.autocrlf flag after cloning the repository?
Issue 83 on the google code project form msysGit goes deeper in on this topic.
If that it the case, doing a new clone should fix the problem (as long as the flag is not touched).
Are you using the Git GUI or Git Bash?
For some reason, Git GUI on Windows does not have core.autocrlf configured by default when cloning a repo, even after attempting to set core.autocrlf in the global configuration using Git Bash (might be GUI setting or environment issue that if corrected, could make the GUI a viable option).
Also, for some reason Git GUI in some cases seems to think it's better to make a master branch in the new repo rather than using the existing branches in the repo being cloned. After Git GUI makes this master branch, it then does a checkout of this master branch immediately after the clone. Since you're using a pull and having issues, this might only have been the issue if you initially cloned using Git GUI.
Most likely, it you're core.autocrlf setting. The following steps should set up a repo for you and ensure the proper crlf settings...
Steps to Clone without Modified File Garbage:
Using the following command in Git Bash from the Windows folder clones the repo as a full copy without making an initial checkout of a branch.
git clone –n --no-hardlinks
By not checking out the branch when cloning, you now have the ability to verify your .git/config file has the correct settings for autocrlf before checking out the branch. You might want to add safecrlf just to be safe ;) To update these settings crlf settings, execute the following commands from your newly cloned Windows repo using Git Bash:
git config core.autocrlf true
git config core.safecrlf warn
To verify the changes made it correctly, open your .git/config file and you should see:
autocrlf = true
safecrlf = warn
PLEASE NOTE: You want autocrlf set to input in your Linux repo... setting to true is for your Windows repo. Also, I only use warn on safecrlf, you may want to use true.
Once you have your crlf configuration set, you can finally checkout the branch normally using git checkout .
If there are still modified files in your new local Windows clone, it's likely due to having CRLF instead of LF in your Linux repo. This can be verified by using a hex editor on the files in your Linux repo and searching to see if 0D0A is present, or if everything is just 0A as it should be.

Resources