It looks to me like this works for git ratchet. But it looks like it probably doesn't work for GitAttributesLineEndings.

1. Have you integration tested this PR on your own use-case?
2. Does your Spotless config set the line endings manually, or does it use the default policy (which is GitAttributesLineEndings)

It looks to me like this works for git ratchet. But it looks like it probably doesn't work for GitAttributesLineEndings.

1. Have you integration tested this PR on your own use-case?
2. Does your Spotless config set the line endings manually, or does it use the default policy (which is GitAttributesLineEndings)

Ah, we do set the line endings manually to UNIX (as a workaround for some other issue), so I guess that's why it was enough for us.

The code in GitAttributesLineEndings looks quite different to the code I was modifying in the other class. I guess the two should be sharing this code somehow, but figuring out how to fit it in might take a while.

figuring out how to fit it in might take a while.

I'd love a PR which figures it out. But I'm also happy to merge this PR as-is if the changelog makes clear that git worktrees are fixed only for ratchetFrom, and they are not fixed for the default lineEndigs GIT_ATTRIBUTES.

What it appears has happened is, getDotGitDir was originally introduced to work around another similar edge case, submodules - but the same workaround wasn't performed in GitAttributesLineEndings at the same time.

So there's this createRepo method in GitRatchet which has both these workarounds now:

	static Repository createRepo(File dir) throws IOException {
		return FileRepositoryBuilder.create(getDotGitDir(dir, Constants.DOT_GIT));
	}

But in GitAttributesLineEndings, there is instead:

			FileRepositoryBuilder builder = new FileRepositoryBuilder();
			builder.findGitDir(projectDir);

which is using the library itself to find the git directory (I'm guessing that what builder.getGitDir() returns is the same .git directory?) Looking inside the findGitDir method it appears that it may already support some of this correctly, because I can see it reading .git as a file and then parsing it for the gitdir: ... string.

So it might be that replacing this logic somehow with a call to createRepo would be the fix for the latter (we'd move it to a utility class nearby so that both can use the same thing) but it's a bit interesting because the latter only uses the builder and never seems to create the actual Repository object, so I'm not quite sure how to make the two work in the same way.

Maybe we just move getDotGitDir to a utility class and then call that from both?

Sounds great!

Working at it but it is a bit of a mess because GitRatchet is generic so that the logic can look at the parent project, but then GitAttributesLineEndings doesn't care whether a parent project exists at all, which is a bit inconsistent. I wanna say a better design might have been to wrap the project object in an adapter so that the same adapter can just be used everywhere, but I can't currently see how everything fits together.

OK, I did some investigation around JGit's FileRepositoryBuilder to see exactly what results it was getting, and what I seem to find is that it supports submodules correctly but just not worktrees. So I can simplify things somewhat by letting it do most of the work and then applying the workaround for the one case where it doesn't work:

	static File getDotGitDir(File projectDir) {
		FileRepositoryBuilder builder = new FileRepositoryBuilder();
		builder.findGitDir(projectDir);
		return resolveRealGitDirIfWorktreeDir(builder.getGitDir());
	}

And then the workaround:

	static File resolveRealGitDirIfWorktreeDir(File dir) {
		File pointerFile = new File(dir, "gitdir");
		if (pointerFile.isFile()) {
			try {
				String content = new String(Files.readAllBytes(file.toPath()), StandardCharsets.UTF_8).trim();
				return new File(content);
			} catch (IOException e) {
				System.err.println("failed to parse git meta: " + e.getMessage());
				return dir;
			}
		} else {
			return dir;
		}
	}

And that method is also what GitAttributesLineEndings needs to do for its case, so I can share a little more code this way.

Amazing!

Published in plugin-gradle 5.17.0 and plugin-maven 2.17.1