From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: some-java-user-99206970363698485155@vodafonemail.de
Cc: git@vger.kernel.org
Subject: Re: Suggestion: Allow .gitattributes to specify executable mode
Date: Sun, 17 Oct 2021 21:11:53 +0000 [thread overview]
Message-ID: <YWyRmT+ln6/p3DjF@camp.crustytoothpaste.net> (raw)
In-Reply-To: <a5a41a53a50448a0829dc3bb8681f5bc@vodafonemail.de>
[-- Attachment #1: Type: text/plain, Size: 2021 bytes --]
On 2021-10-17 at 20:56:05, some-java-user-99206970363698485155@vodafonemail.de wrote:
> Hello,
>
> some build systems have script files with certain specific names which are always intended to be executable.
> For example Gradle has a `gradlew` file, and Maven has a (currently unofficial) `mvnw` file.
>
> For Windows users these script files often cause problems when checked in with Git and used by a CI (continuous
> integration) system running Linux. The CI build usually fails because the script files do not have the executable
> flag set (Windows does not have this concept).
>
> Would it be possible to extend the `.gitattributes` file to allow specifying that files should automatically get
> the executable flag when added to the index? For example Gradle's `gradle init` command already creates a
> `.gitattributes` file; it could then add such a default entry to ease development for Windows users to make sure
> they add the `gradlew` script file with the correct file mode.
>
> Assuming the flag is called `exec`, Gradle could then create the following `.gitattributes` entry:
> ```
> gradlew text exec
> ```
>
> It might also help with questions such as https://stackoverflow.com/q/14267441.
>
> What do you think?
I think this might end up being duplicative on Unix systems, but you
could implement this with a pre-commit hook if you wanted. Something
like this might work:
#!/bin/sh
files=$(git ls-files | git check-attr --stdin exec | grep 'exec: set$' | awk -F': ' '{print $1}')
files=$(git ls-files -s $files | grep '^100644' | awk -F'\t' '{print $2}')
git update-index --chmod=+x $files
git add $files
This obviously doesn't handle filenames with spaces, so it would need
some improvements, but it might work for your case.
It may also be beneficial to actually check this in CI as a first sanity
check, although it sounds like this CI system does this implicitly.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
prev parent reply other threads:[~2021-10-17 21:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-17 20:56 Suggestion: Allow .gitattributes to specify executable mode some-java-user-99206970363698485155
2021-10-17 21:11 ` brian m. carlson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YWyRmT+ln6/p3DjF@camp.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=git@vger.kernel.org \
--cc=some-java-user-99206970363698485155@vodafonemail.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).