Closed HenryLoenwind closed 4 months ago
HenryLoenwind commented 1 minute ago Why do you think your code knows better if something is a git repo than the actual git repo?
Keep up the attitude and see how much help that gets you. Try being polite instead of rude from the get go.
PS: VERSION=42 ./gradlew build
works fine. Just that I don't need a build, I want to open it in eclipse
final boolean isAGitRepo = Files.exists(projectDir.resolve(".git"));
Your version of git is clearly looking at something that isn't standard from what I've seen; every checkout I've had puts the files in .git.
You can set a VERSION env var in eclipse, setup a standard git repo, or submit a PR against gtnh gradle to identify new and/or non standard git setups
Which version of git are you using
Hey can we please act and argue as grown ups ? Thank you Maybe a discussion on Discord could be more helpful then just put here a wall of text ?
Keep up the attitude and see how far that gets you.
I'd suggest you work on your attitude. Have a look at the original ticket:
I started it off with proof that the project is in git controlled by running a git command right after the build failure. I asked how to disable it, as the error message only says to disable it but doesn't give any hint on how---the build.gradle is rather empty and there's nothing in the gradle-properties. I even added that setting an environment variable is not an option as you cannot set one in Eclipse for the gradle process.
You closed the ticket with the very unhelpful comment of "that's no git repo".
I told you that git recognises it as a git repo.
You doubled down on "that's no repo".
So again, I'm not interested in how to get the gitVersion thing working. I'm not building the project---I built and published it weeks ago and so far it's been working without any issues. I simply wanted to open the thing because I wanted to compare a 1.7.10 Forge class with a 1.21 class. I shouldn't even need any kind of version for opening the project in Eclipse.
Also, Eclipse doesn't have the capability of setting environment variables for the automatic background "configure project" gradle run. It can do that for launch configurations and it may have some for manual gradle task runs. But not for the background stuff it uses to query the project setup from gradle.
But as you provided the code link, I went through it and found the error. It is using a very straightforward (and wrong) way of checking for a git repo. Instead of asking the GitVersionPlugin, it checks for the .git folder. While the GitVersionPlugin can get the tag version from any folder of a git repo, that .git folder only exists once for the whole repo—at the top level. So, creating a fake empty .git folder allows it to run.
However, there's something weird anyway. On the command line, all is well, and it correctly picks up the latest tag (and commit and changed files):
$ ./gradlew build
> Configure project :
You might want to check out './gradlew :faq' if your build fails.
Deprecated: Allowing insecure connections for repo 'maven' - add 'allowInsecureProtocol = true' to silence
This project uses deprecated `compile` dependencies, please migrate to using `api` and `implementation`
For more details, see https://github.com/GTNewHorizons/ExampleMod1.7.10/blob/master/dependencies.gradle
Build script update from 1.0.21 to 1.0.23 available! Run ./gradlew updateBuildScript
> Task :compileJava
Jabel: initialized
Note: SpongePowered MIXIN Annotation Processor Version=0.8.5
Note: Supported obfuscation types: ObfuscationServiceMCP supports [searge,notch]
Note: Loading searge mappings from C:\Users\xxx\.gradle\caches\minecraft\net\minecraftforge\forge\1.7.10-10.13.4.1614-1.7.10\srgs\mcp-srg.srg
Note: Writing refmap to D:\git\gravity_torch\1.7.10\build\tmp\mixins\mixins.gravitytorch.refmap.json
Note: Writing refmap to D:\git\gravity_torch\1.7.10\build\tmp\mixins\mixins.gravitytorch.refmap.json
Note: Writing searge output SRGs to D:\git\gravity_torch\1.7.10\build\tmp\mixins\mixins.srg
Note: Writing refmap to D:\git\gravity_torch\1.7.10\build\tmp\mixins\mixins.gravitytorch.refmap.json
Note: Writing refmap to D:\git\gravity_torch\1.7.10\build\tmp\mixins\mixins.gravitytorch.refmap.json
Note: Writing searge output SRGs to D:\git\gravity_torch\1.7.10\build\tmp\mixins\mixins.srg
BUILD SUCCESSFUL in 21s
$ ls -ltr build/libs/
total 1008
...
-rwxrwx---+ 1 xxx None 43435 Jul 7 09:28 gravitytorch-v2.0.4-master.1+4c5bc4c907-dirty-dev.jar
-rwxrwx---+ 1 xxx None 43824 Jul 7 09:28 gravitytorch-v2.0.4-master.1+4c5bc4c907-dirty.jar
-rwxrwx---+ 1 xxx None 20354 Jul 7 09:28 gravitytorch-v2.0.4-master.1+4c5bc4c907-dirty-sources.jar
But in Eclipse it still is complaining (but at least not rejecting):
> Configure project :
This mod must be version controlled by Git AND the repository must provide at least one tag,
or the VERSION override must be set! (Do NOT download from GitHub using the ZIP option, instead
clone the repository, see https://gtnh.miraheze.org/wiki/Development for details.
Version override set to NO-GIT-TAG-SET!
You might want to check out './gradlew :faq' if your build fails.
Deprecated: Allowing insecure connections for repo 'maven' - add 'allowInsecureProtocol = true' to silence
This project uses deprecated `compile` dependencies, please migrate to using `api` and `implementation`
For more details, see https://github.com/GTNewHorizons/ExampleMod1.7.10/blob/master/dependencies.gradle
Build script update from 1.0.21 to 1.0.23 available! Run ./gradlew updateBuildScript
> Task :nothing UP-TO-DATE
BUILD SUCCESSFUL in 7s
May I also state that I find it a very curious decision to throw
for a missing version number on any gradle task other than build
? Even ./gradlew tasks
fails.
An issue has been made here https://github.com/GTNewHorizons/GTNHGradle/issues/17
I again looked at the original ticket; last night I looked at it on mobile and since it was a screenshot instead of text it was easy to miss the part where you checked the git version.
I didn't double down on anything, just pointed out I wasn't assuming anything and was reading the screenshot provided.
99.5% of every other issue anyone else has had along these lines was because they downloaded the zip or didn't create a repo/commit -- Occam's Razor - that's generally the solution.
The ticket was closed because you were getting argumentative and saying I was assuming things, instead of moving it forward in a helpful manner of pointing out my oversight nicely and laying out the fact patterns, even on this ticket your first line was quite passive aggressive.
Why do you think your code knows better if something is a git repo than the actual git repo?
Should I open a ticket against git to tell them their command is having hallucinations about seeing a git repo that doesn't exist?
Also, I'm not even trying to build the project. For that I can override with the environment variable manually. I'm trying to open it in Eclipse. Just OPEN it to look at the code. And even Eclipse sees it as a git repo.