bit-man / swissarmyjavagit Goto Github PK

Currently there's a quite basic git clone implementation, with no options at all

Hi there,

I am trying to use this Library on Windows and have problems setting the gitpath for my standard installation of mysysgit. The "git.exe" resides in "C:\Program Files (x86)\Git\bin".

I think the problem is, that

   JavaGitConfiguration.determineGitVersion()

Is evaluating the pure "git" command, without the windows related .exe extension.
Here's the stacktrace:

edu.nyu.cs.javagit.api.JavaGitException: 100002: Invalid path to git specified. { path=[C:\Program Files (x86)\Git\bin] }
    at edu.nyu.cs.javagit.api.JavaGitConfiguration.setGitPath(JavaGitConfiguration.java:220)
    at edu.nyu.cs.javagit.api.JavaGitConfiguration.setGitPath(JavaGitConfiguration.java:247)
    at net.lidl.gitwatcher.git.GitRepositoryHandlerTest.testJavaGitConfigurationSetGitPath(GitRepositoryHandlerTest.java:44)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
    at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
Caused by: edu.nyu.cs.javagit.api.JavaGitException: 100002: Invalid path to git specified.
    at edu.nyu.cs.javagit.api.JavaGitConfiguration.determineGitVersion(JavaGitConfiguration.java:81)
    at edu.nyu.cs.javagit.api.JavaGitConfiguration.setGitPath(JavaGitConfiguration.java:217)

Now I am wondering what I am doing wrong, as the README says this has been tested on windows?

To keep the change pace with Git command parameters passing extra parameters to Git commands should be added. This will help not only to keep pace (Git 2.0 is here !!) but to implement many commands with just no parameter and letting the user to pass them and use full Git power

See TestGitCheckout.testCreatingNewBranchFromMaster() where GitCheckoutResponse.getNewBranch().getName() returns the branch name but "decorated" with single or double quotes.
I surely will change it to not add the quotes but this will break backwards compatibility.
Ask to JavaGit people and try to locate users of the old JavaGit code and learn from them

Can you add fetch support

Can you make 0.2.0 available in Maven central?

    <dependency>
        <groupId>javagit</groupId>
        <artifactId>javagit</artifactId>
        <version>0.2.0</version>
    </dependency>

https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

While I would like to use this library I'm a little reluctant as I see most changes 7 years ago is this actively developed?

When "git add -u" and "git add -A", that does not specify what paths to add on the command line, is run from inside a subdirectory, the scope of the operation has always been limited to the subdirectory. Many users found this counter-intuitive, given that "git commit -a" and other commands operate on the entire tree regardless of where you are. In this release, these commands give warning in such a case and encourage the user to say "git add -u/-A ." instead when restricting the scope to the current directory.

Backward compatibility notes (for Git 2.0)

When "git add -u" (and "git add -A") is run inside a subdirectory and
does not specify which paths to add on the command line, it
will operate on the entire tree in Git 2.0 for consistency
with "git commit -a" and other commands. There will be no
mechanism to make plain "git add -u" behave like "git add -u .".
Current users of "git add -u" (without a pathspec) should start
training their fingers to explicitly say "git add -u ."
before Git 2.0 comes. A warning is issued when these commands are
run without a pathspec and when you have local changes outside the
current directory, because the behaviour in Git 2.0 will be different
from today's version in such a situation.

Add missing implemented commands to DotGit

Publish JavaGit into http://search.maven.org/

Add build status as currently performed in PIP : https://raw.github.com/pypa/pip/develop/README.rst

Add a log that shows each git command executed

When trying to add a file containing space(s) in its path JavaGit fails with the next error :

Caught: edu.nyu.cs.javagit.api.JavaGitException: 401000: Error calling git-add. - git add error message: { Line 1. fatal: pathspec 'tools.iml' did not match any files }
edu.nyu.cs.javagit.api.JavaGitException: 401000: Error calling git-add. - git add error message: { Line 1. fatal: pathspec 'tools.iml' did not match any files }
at edu.nyu.cs.javagit.client.cli.CliGitAdd$GitAddParser.getResponse(CliGitAdd.java:276)
at edu.nyu.cs.javagit.client.cli.CliGitAdd$GitAddParser.getResponse(CliGitAdd.java:167)
at edu.nyu.cs.javagit.client.cli.ProcessUtilities.runCommand(ProcessUtilities.java:145)
at edu.nyu.cs.javagit.client.cli.CliGitAdd.add(CliGitAdd.java:49)
at edu.nyu.cs.javagit.client.cli.CliGitAdd.add(CliGitAdd.java:74)
at edu.nyu.cs.javagit.api.commands.GitAdd.add(GitAdd.java:218)
at edu.nyu.cs.javagit.api.commands.GitAdd$add.call(Unknown Source)

When there's unless one file modified (and shown under "Changes not staged for commit") the outputstate is not set and causes an NPE when adding the modified file

This happens only if this is the first block shown in git status output

When determining git version or obtaining the git command prefix the classpath separator was used instead of path separator.

In Linux this means that instead of trying to execute "/usr/bin/git" tries to run "/usr/bin:git"