Skip to main content

Set execute permission with Git from Windows

At my work, I am working usually with Windows. But when we started our migration to Linux Docker containers and Kubernetes, I've found one annoying issue. Once you create a bash file on Windows, push it to Git and after this, you try to execute this file in most cases, you will get a “Permission Denied” error.

But it turns out the solution is quite easy. So I am sharing it here, so it can maybe help you (or me) in the future.

The solution is the Git update-index command.
To set the execute permission you can use this command:
git update-index --chmod=+x path/to/file
To remove it, use:
git update-index --chmod=-x path/to/file
This will assign execute permission to the selected bash file. The only thing missing is to push the changes to the Git repository.

Deeper look

Let's check what is happening here underhood. Under the hood, Git doesn't have a unix files permission system. In reality, Git maintains a special "mode" for each file in its internal storage:
  • 100644 for all regular files
  • 100755 for executable files 
By default, when you add a file to a repository, Git will try to set the correct file mode accordingly.  But sometimes it fails.

To check file's file mode you can use ls-files command with the option --stage:
$ git ls-files --stage
100644 1ff0c423042b46cb1d617b81efb715defbe8054d 0       .gitattributes
100644 3c4efe206bd0e7230ad0ae8396a3c883c8207906 0       .gitignore
100755 1a82e9a4560497d8c6e273c61bfd01995524d58f 0       my_executable_script.sh
Thank you for reading, I hope this will help someone.

Comments

Post a Comment

Popular posts from this blog

How to Build TypeScript App and Deploy it on GitHub Pages

Quick Summary In this post, I will show you how to easily build and deploy a simple TicksToDate time web app like this: https://zubialevich.github.io/ticks-to-datetime .

Pros and cons of different ways of storing Enum values in the database

Lately, I was experimenting with Dapper for the first time. During these experiments, I've found one interesting and unexpected behavior of Dapper for me. I've created a regular model with string and int fields, nothing special. But then I needed to add an enum field in the model. Nothing special here, right? Long story short, after editing my model and saving it to the database what did I found out? By default Dapper stores enums as integer values in the database (MySql in my case, can be different for other databases)! What? It was a surprise for me! (I was using ServiceStack OrmLite for years and this ORM by default set's enums to strings in database) Before I've always stored enum values as a string in my databases! After this story, I decided to analyze all pros and cons I can imagine of these two different ways of storing enums. Let's see if I will be able to find the best option here.

Caching strategies

One of the easiest and most popular ways to increase system performance is to use caching. When we introduce caching, we automatically duplicate our data. It's very important to keep your cache and data source in sync (more or less, depends on the requirements of your system) whenever changes occur in the system. In this article, we will go through the most common cache synchronization strategies, their advantages, and disadvantages, and also popular use cases.

How to maintain Rest API backward compatibility?

All minor changes in Rest API should be backward compatible. A service that is exposing its interface to internal or/and external clients should always be backward compatible between major releases. A release of a new API version is a very rare thing. Usually, a release of a new API version means some global breaking changes with a solid refactoring or change of business logic, models, classes and requests. In most of the cases, changes are not so drastic and should still work for existing clients that haven't yet implemented a new contract. So how to ensure that a Rest API doesn't break backward compatibility?