Skip to content

copier update loses executable bit on NEW files introduced by the template when core.fileMode=false #2630

Description

@willemkokke

Follow-up to #2605.

#2605 fixes executable-bit propagation for files that already exist in the destination. But files introduced by the template for the first time on a copier update run are still affected when core.fileMode=false:

  1. Template v2 adds a new script.sh with 100755 in the index.
  2. Destination has core.fileMode=false (Windows default, and a common opt-out elsewhere).
  3. copier writes the file, chmods it on disk (invisible to git with fileMode=false), then calls _sync_git_index_executable_bit — which short-circuits because the file is untracked.
  4. The user's next git add script.sh records 100644 because git ignores on-disk mode with fileMode=false. Exec bit is lost.

Suggested approach, from @sisp's review on #2605: run git add --intent-to-add <file> for new files introduced by the template. This registers an index entry (without a blob), after which git update-index --cacheinfo can set the correct mode. The intent-to-add marker is also a nice semantic signal that these files aren't random untracked content but deliberate template output.

This is a separate PR / changelog entry because it expands copier's update algorithm with a new feature, rather than fixing a regression on existing behavior.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions