The man page says
ENVIRONMENT AND CONFIGURATION VARIABLES
The editor used to edit the commit log message will be chosen from the GIT_EDITOR environment variable, the core.editor configuration variable, the VISUAL environment variable, or the EDITOR environment variable (in that order).
So in order to make nano our default editor we can do
git config --global core.editor "nano"
--global means this will become a default setting for all of git (leaving it out would only affect the current git repo you are running the command from)
What git is trying to say here is that the mode of the files have changed, the content of the file is still the same.
If this is common and the filemodes are not important for this project we can simply tell git to ignore this.
Either by telling git to do this as default or only for this project.
git config core.filemode false
Only for this project edit .git/config
And in case we do need to check in single filemode changes the following works
git update-index --chmod=(+|-)x path/to/file
This will start out with an error such as the following:
$ git pull origin master
error: SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed while accessing https://github.com/mopidy/mopidy.git/info/refs
If it is acceptable to turn off the SSL validation instead of actually solving the issue this will turn off validation for the current repo
git config --local http.sslVerify false
If you would rather have this as a default behaviour for git then the following will do it for all repos
git global --local http.sslVerify false
and for those that would rather add to the .git/config file directly the entry looks like
Pretend we just did a “git rm” but realized that we wish to keep one file we just removed.
git checkout HEAD path/to/file
This will simply checkout the file from the HEAD revision.
Another alternative is to use git reset if it is more files and no other changes are uncommitted (or stage before doing the reset)
Lets say that there is an existing repository that we should pull the files from.
git remote add origin user@server:remote-repo
git pull origin master
What is done here is
- git init Initializes the directory as a git repository (creates .git directory and add needed files)
- git remote add name url adds a remote repository with a name (origin) and url (user@server:remote-repo)
- git pull name branch pull the existing content from the given brach (master)
The main difference bewteen this and creating a new remote repository is that no files are added and no initial commit is being made – since there is content in the remote repository we are joining.
In order to stop tracking a file in git then rm is used – however this will delete the file from my local directory as well. The following will stop tracking the file, but keep it on my local computer.
git rm --cached path/filename
After this step, it is very likely that the file should be added to a .gitignore file;)
If you need to remove a file from the list of files about to be committed then “git reset” will undo the git add.
It will only remove it from the staging area, it will not change the contents of the file.
Sometimes we make attempts that go nowhere or simply edit the wrong file. When this happens it is nice to just “undo” what I did and revert the file back to the last good state (I assume the state I have gotten/pushed to is good).
I can revert the file to the latest version
Or I can revert it to the latest version from the HEAD revision
git checkout HEAD the.file
Or I could do it for the entire working tree
Lets say we want to add any and all folders called “build” regardless of where in the directory structure.
Git will by default check each file (and directory), adding limitations will limit when the pattern matches, so actually just typing what you wish to ignore is a global patter.
With git this would be done by adding the following to the .gitignore file
#ignore the folder called build anywhere, but not files called build
Also note that if the directory is already tracked in git, .gitignore will not affect that – it will remain tracked and changes can be committed etc.
Since this has a “/” at the end only directories would be matched – removing it would also make the pattern catch files with the same name.