How to avoid file mode changes in go-git?

[JeffreySE]

👍 Awesome project! it helped me a lot.
Currently, I'm facing the file mode changing issues in my project.

old mode 100644
new mode 100755

Per the "How do I make Git ignore file mode (chmod) changes?" q&a in StackOverflow, I tried to set the filemode setting to false into the git config file under the cloned repo. But it doesn't work.

$ cat .git/config
[core]
        filemode = false
        bare = false
[remote "origin"]
        url = https://xxxx.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master

I also found a similar issue in the old repo: Changing file mode on NTFS #866
Did anyone know how to avoid this kind of issue in go-git? Thank you!

[johnmccabe]

Did you ever get a workaround/solution for this, I'm hitting the same problem in WSL.

[JeffreySE]

Hmm, I wrapped the git binary as a standard client finally. It brings a binary dependency but works great till now.

[jceb]

Same here. Unfortunately, a bunch of functions need to be replaced: checkout and reset are two that I ran into.

[github-actions]

To help us keep things tidy and focus on the active tasks, we've introduced a stale bot to spot issues/PRs that haven't had any activity in a while.

This particular issue hasn't had any updates or activity in the past 90 days, so it's been labeled as 'stale'. If it remains inactive for the next 30 days, it'll be automatically closed.

We understand everyone's busy, but if this issue is still important to you, please feel free to add a comment or make an update to keep it active.

Thanks for your understanding and cooperation!

[pjbgf]

It would be good if anyone still experiencing this could confirm whether this is also the case when using osfs.New(path, osfs.WithBoundOS()).

[craigbrett17]

I came here because I'm facing the same issue.

I'm not sure if this is exactly how you meant your above suggestion to be used, so I guessed:

func (c *GitClient) GetFromDirectory(dir string) (*git.Repository, error) {
	fs := osfs.New(dir, osfs.WithBoundOS())
	return git.PlainOpen(fs.Root())
}

Unfortunately, this did not resolve the issue, and I'm still seeing the file mode changes.

[pjbgf]

@craigbrett17 can you please provide an example repository so folks can try to reproduce/fix the issue?

[craigbrett17]

Unfortunately I didn't come across this whilst doing some noble and fulfilling open source volunteering, but as part of work, so the repository is private.

I'll throw something together that uses this library to illustrate this if that'll help.

[craigbrett17]

@pjbgf As requested, I've put together a working example that reproduces this reliably on Windows.

https://github.com/craigbrett17/go-git-buggy

Absolutely meant as an example repository, so please treat it as such.

Any help gratefully appreciated.

[pjbgf]

@craigbrett17 the "Plain" versions of the go-git commands use the default fs, can you please try again with:

func (c *GitClient) Clone(dir string, organisation string, repo string) (*git.Repository, error) {
	repositoryName := fmt.Sprintf("https://github.com/%s/%s.git", organisation, repo)
	wt := osfs.New(dir, osfs.WithBoundOS())
	dotfs, err := wt.Chroot(git.GitDirName)
	if err != nil {
		return nil, err
	}
	store := filesystem.NewStorage(dotfs, cache.NewObjectLRUDefault())

	repository, err := git.Clone(store, wt, &git.CloneOptions{
		URL:      repositoryName,
		Progress: os.Stdout,
		Depth:    1,
	})

	return repository, err
}

func (c *GitClient) LoadFromDirectory(dir string) (*git.Repository, error) {
	wt := osfs.New(dir, osfs.WithBoundOS())
	dotfs, err := wt.Chroot(git.GitDirName)
	if err != nil {
		return nil, err
	}
	store := filesystem.NewStorage(dotfs, cache.NewObjectLRUDefault())
	return git.Open(store, wt)
}

[craigbrett17]

@pjbgf I gave this a try, no dice I'm afraid. I still see these file mode changes as before. Feel free to give it a try yourself if you have access to a Windows machine.

[github-actions]

To help us keep things tidy and focus on the active tasks, we've introduced a stale bot to spot issues/PRs that haven't had any activity in a while.

This particular issue hasn't had any updates or activity in the past 90 days, so it's been labeled as 'stale'. If it remains inactive for the next 30 days, it'll be automatically closed.

We understand everyone's busy, but if this issue is still important to you, please feel free to add a comment or make an update to keep it active.

Thanks for your understanding and cooperation!