git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

      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).