How To Ignore Mode Changes In Git

25th June 2012 - 2 minutes read time

Note: This post is over a year old and so the information contained here might be out of date. If you do spot something please leave a comment and I will endeavour to correct.

Git will track changes to files and directories, including any changes to permissions done via chmod. In most development environments I tend to have a different set of permissions to those on the live site so I am usually not interested in tracking permissions changes. To prevent git from looking at the difference between the permissions of a file you need to set the core.filemode configuration option to false.

git config core.filemode false

Here is the entry from the git-config(1) manual page.

core.fileMode
   If false, the executable bit differences between the index and the working tree are ignored; useful on broken 
   filesystems like FAT. See git-update-index(1).
 
   The default is true, except git-clone(1) or git-init(1) will probe and set core.fileMode false if appropriate 
   when the repository is created.

This information was originally taken from this post on Stackoverflow. I am always forgetting how to do this, so as an aid to memory I am writing this post.

git

Add new comment

Committing The Composer Vendor Directory

When installing composer dependencies those dependencies are downloaded and stored in the 'vendor' directory. There are options available to install this into a different location than the composer.json file, but it's generally found in the same directory. The vendor directory contains quite a bit of code, which is especially the case if your project contains quite a lot of dependencies. More often than not though, this directory will not contain any code that you have actually written. It will contain the necessary third party libraries that allow your code to work correctly.

Tidying Up A Git Repo

Creating branches in git basically free and is easy to do. This has lead to the development of techniques like git flow and other branch related work streams, which are now commonplace in development.

If you have a project being worked on by many developers you can get into the situation where there are many branches in the project. Some will be merged, some will be worked on currently and some more will be branches that were worked on, but never finished (for one reason or another). This can lead to some confusion over what branches are being worked on, especially if you want an oversight on the current health of the project.

Force Update Of Git Repository

If you have changed or updated a git repository and want to throw away your changes then a good way of forcing the latest changes to run a combination of two commands. The first command is git fetch --all, which tells git to download the latest updates from the remote without trying to merge or rebase anything. This is followed by git reset --hard origin/master where git resets the master branch (assuming you were on the master branch) to become the version of the master branch you just fetched. Here is the two commands in full:

git fetch --all
git reset --hard origin/master

There are a few reasons why you might want to do this but should remember that any changes you have made to files in the repository will be binned in favour of the latest version.

Find The Number Of Commits In A Git Repository

Use the following command to find out how many commits there have been in a git repository. Not really useful in itself, but an interesting figure to see how active a project has been over it's lifetime.

git log --oneline --all | wc -l

The following git log flags are in use here:

--oneline - Removes some of the information from the log entries and displays each on a single line.

--all - Shows all commits across all branches.

The -l (lower case L) flag is supplied to the wc command so that it counts the number of lines in the given input.