Gitmoji: Emoji suggestion: Updating file permissions (e.g. for chmod +x)

[DanielHilton]

Hello @carloscuesta :sunglasses:!

• Emoji: ✋
• Code: :hand:
• Description: When a commit is being made that contains permissions changes (usually using chmod) for files, for example to make them executable or not.

I use gitmoji in my team and have authored a commit purely for changing file permissions, to not find one. Therefore I propose the :hand: emoji for this, as it can represent a hand denying permission to someone/something. Am happy to accept other suggestions too.

[ETLaurent]

Nice one, I suggest ⛔, or 🛑 🔑 🚫

[broccolai]

🔑 makes the most sense to me.

[raabf]

Note that git does not store real file permissions. The only thing which is stored in git, is the executable bit x. So a file can be only executable (mode 755) or not (mode 644), nothing other.

Since :key: can be interpreted in may different ways (for example #231 ) and it is a matter of just executable or not, probably something run related fits better. For example
🚸 or 🏃‍♀️ or 🏃

I would prefer 🚸 over the other two, since it looks more like a permission and that something is able to run (like an executable bit) instead of actively running like the other two.

[grissius]

Heya @DanielHilton
This is interresting. While I like the idea, I think it is very rare to update file permissions. In my expirience there is a single commit in a regular repo (or none in even more ordinary repo) when you forget to set the permissions of a CLI.

At this point I don't think that the use case is so common to make sence to introduce the symbol. Do you agree? If not, can you point to a repo or few, where changing permissions is a thing?

Thanks for proposal 😸

[DanielHilton]

Im my personal experience, it's useful for new development when (many a time) i have forgotten and pushed a script to a repository only to find when it is executed by my build server with ./run.sh it fails. I need to then commit and push a change only to change the executable permission flag on the file; which then prompted me to find there was no such emoji for this.

[Stivaros]

This feels quite niche to me and seems DevOpsy. Personally, I don't think we need something so narrow in scope but I do think it highlights a good option for scripting and infrastructure work. I'm aware we have gitmoji for kubernetes and Docker :)

Thoughts?

[KaKi87]

Note that git does not store real file permissions.

That's it.

The only thing which is stored in git, is the executable bit x.

What about 🔧 for this ?

[carloscuesta]

Dont think it's worth to add this as a gitmoji

[raabf]

🔧 is already used by “Adding or updating configuration files.”

I would also say that changing permissions is rare enough, that learning a new gitmoji is not worth.

However, we could at least think of, under which gitmoji this is already covered and probably add it to the description.
“🔒 Fixing security issues.”: File permissions are for security reasons, but with this emoji you usually mean security issues within the application you develop and store in the repository
“🚚 Moving or renaming files.”: File permissions does not change the path a file, but its file state which is also true when changing the file path. I would prefer this gitmoji and add to its description “or change file permissions”.

[KaKi87]

Dont think it's worth to add this as a gitmoji

🔧 is already used by “Adding or updating configuration files.”

@carloscuesta @raabf I meant : what about using this existing gitmoji for these kind of commits ?

[raabf]

@KaKi87 Oh sorry then I misunderstood that :sweat_smile: . Mhmm
🔧 “Adding or updating configuration files.”: Would be possible, changing permissions is some kind of configuration of the repository, but the executable bit is usually set on binaries or scripts, but not on configuration files. With 🔧 I would expect that a script has afterwards some different behaviour, which would not be the case for setting executable bit; so I personally would not relate that.

[KaKi87]

What about removing files and just keeping Adding or updating configuration ?

[carloscuesta]

Based on the upvotes I think we should discard this proposal.

Thanks @danielhilton!