search

HPI-Information-Systems / Metanome

The source repository of the Metanome tool
metanome.de
Apache License 2.0
171 stars 62 forks source link

Build fails with Git 1.7.1 #370

Closed sekruse closed 3 years ago

sekruse commented 7 years ago

When trying to build Metanome with Git 1.7.1, the checkout of the frontend project fails:

Usage: git submodule [--quiet] add [-b branch] [--reference <repository>] [--] <repository> [<path>]
   or: git submodule [--quiet] status [--cached] [--recursive] [--] [<path>...]
   or: git submodule [--quiet] init [--] [<path>...]
   or: git submodule [--quiet] update [--init] [-N|--no-fetch] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
   or: git submodule [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
   or: git submodule [--quiet] foreach [--recursive] <command>
   or: git submodule [--quiet] sync [--] [<path>...]
[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1)
    at org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:404)
    at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:166)
    at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:764)
    at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:711)
    at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:289)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

The problem seems to be that the --remote parameter is not supported in Git 1.7.1. I am not sure, if we need this parameter at all. Here is the explanation (Git 2.7.2):

       --remote
           This option is only valid for the update command. Instead of using the superproject's recorded SHA-1 to update the
           submodule, use the status of the submodule's remote-tracking branch. The remote used is branch's remote
           (branch.<name>.remote), defaulting to origin. The remote branch used defaults to master, but the branch name may be
           overridden by setting the submodule.<name>.branch option in either .gitmodules or .git/config (with .git/config
           taking precedence).

           This works for any of the supported update procedures (--checkout, --rebase, etc.). The only change is the source
           of the target SHA-1. For example, submodule update --remote --merge will merge upstream submodule changes into the
           submodules, while submodule update --merge will merge superproject gitlink changes into the submodules.

           In order to ensure a current tracking branch state, update --remote fetches the submodule's remote repository
           before calculating the SHA-1. If you don't want to fetch, you should use submodule update --remote --no-fetch.

           Use this option to integrate changes from the upstream subproject with your submodule's current HEAD.
           Alternatively, you can run git pull from the submodule, which is equivalent except for the remote branch name:
           update --remote uses the default upstream repository and submodule.<name>.branch, while git pull uses the
           submodule's branch.<name>.merge. Prefer submodule.<name>.branch if you want to distribute the default upstream
           branch with the superproject and branch.<name>.merge if you want a more native feel while working in the submodule
           itself.
sekruse commented 7 years ago

Removing this line seems to fix the problem.