You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Ilya Basin (JIRA)" <ji...@apache.org> on 2018/05/14 18:38:00 UTC

[jira] [Comment Edited] (SCM-868) gitexe add() does not return added files when invoked in subdir

    [ https://issues.apache.org/jira/browse/SCM-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16474598#comment-16474598 ] 

Ilya Basin edited comment on SCM-868 at 5/14/18 6:37 PM:
---------------------------------------------------------

[~michael-o] Done.

I modified GitCheckInCommandNoBranchTest to demonstrate the problem. The system property "scm.test.tmpdir" now alters the test directory location. Default is "target/".

Please checkout my branch and run:
{code:java}
mvn test -Dtest="GitCheckInCommandNoBranchTest#testCheckinNoBranch" -Dscm.test.tmpdir=D:\
{code}
It should succeed. Then revert the last commit (my fix) and repeat. It should fail with:
{code}
GitCheckInCommandNoBranchTest.testCheckinNoBranch:76 expected:<1> but was:<0>
{code}


was (Author: basinilya):
[~michael-o] Done.

I modified GitCheckInCommandNoBranchTest to demonstrate the problem. The system property "scm.test.tmpdir" now alters the test directory location. Default is "target/".

Please checkout my branch and run:
{code:java}
mvn test -Dtest="GitCheckInCommandNoBranchTest#testCheckinNoBranch" -Dscm.test.tmpdir=D:\{code}
It should succeed. Then revert the last commit (my fix) and repeat. It should fail with:
{code:java}
GitCheckInCommandNoBranchTest.testCheckinNoBranch:76 expected:<1> but was:<0>{code}

> gitexe add() does not return added files when invoked in subdir
> ---------------------------------------------------------------
>
>                 Key: SCM-868
>                 URL: https://issues.apache.org/jira/browse/SCM-868
>             Project: Maven SCM
>          Issue Type: Bug
>          Components: maven-scm-provider-gitexe
>    Affects Versions: 1.9.5, 1.9.6
>            Reporter: Ilya Basin
>            Priority: Major
>
> I'm going to add a wagon-scm test suite for git. One of the test cases is calling the GitAddCommand command with:
> {code:java}
> repo: file:///C:/progs/maven/maven-wagon/wagon-providers/wagon-scm/target/test-classes/test-repo-git-test/
> fileSet: basedir = C:\Users\basin\AppData\Local\Temp\wagon-scm2020146470.checkout\file-list; files = [test-resource.txt]{code}
> After adding the files the command internally calls "git rev-parse --show-toplevel" which prints:
> {code:java}
> C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout{code}
> And on the next line it tries to do (pseudo code):
> {code:java}
> ("file:/C:/Users/basin/AppData/Local/Temp/wagon-scm1144102340.checkout/file-list/").relativize(URI.create(
> "C:/Users/basin/AppData/Local/Temp/wagon-scm2020146470.checkout")){code}
> This is so wrong! What were those people from SCM-709 trying to get? A double dot ".."? The argument to the relativize() method MUST be a child, not a parent, otherwise the argument is returned unchanged.
> There are so many reasons why getting an absolute path from git is a bad idea: Symlinks, Windows paths.
> Nevertheless, there's a simple solution. The original problem was that "git status --porcelain" printed paths relative to the top level instead of relative to the base dir.
> So we should just call 
> {code}
> git rev-parse --show-prefix
> {code} instead of "show-toplevel" and strip this prefix from the paths printed by "git status"



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)