Build fails with Git 1.7.1
Closed this issue · 1 comments
sekruse commented
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.