-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[#1682] Fix space in local repo causing cloning exception #1685
[#1682] Fix space in local repo causing cloning exception #1685
Conversation
…m:chan-j-d/RepoSense into 1657-escape-special-chars-in-bash-command
@@ -160,7 +160,7 @@ public static void cloneBare(RepoConfiguration config, Path rootPath, | |||
*/ | |||
public static void cloneFromBareAndUpdateBranch(Path rootPath, RepoConfiguration config) | |||
throws GitCloneException, IOException { | |||
Path relativePath = rootPath.relativize(FileUtil.getBareRepoPath(config)); | |||
Path relativePath = FileUtil.getBareRepoPath(config); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As of this PR, the cloneFromBareAndUpdateBranch is the only one that does not run the command from the current directory.
Can I clarify if cloneFromBareAndUpdateBranch
is also run from the current directory with the removal of relativize? Could include details about this change in the commit message as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way it works at the moment is somewhat strange. Suppose our working directory is /directory/
, then the rootPath
here (in the only instance where this method is used) is in /directory/repos/
where repos
is a hard-coded constant designated for where the cloned repos go.
FileUtil::getBareRepoPath
would construct something like repos/reposense/reposense_bare
. Code below:
RepoSense/src/main/java/reposense/util/FileUtil.java
Lines 254 to 257 in c656433
public static Path getBareRepoPath(RepoConfiguration config) { | |
return Paths.get(FileUtil.REPOS_ADDRESS, | |
config.getRepoFolderName(), config.getRepoName() + BARE_REPO_SUFFIX); | |
} |
So the relativize
ends up trying to relativize the paths /directory/repos/
and repos/reposense/reposense_bare
which settles on /directory/repos/reposense/reposense_bare
.
The ReportGenerator
class was changed together with the above code and now runs from current directory, /directory/
and then adds on the entire bare repo path to the back. Functionally, it is the same.
I have updated it in the commit message as well.
@@ -55,7 +55,7 @@ public static CommandRunnerProcess cloneShallowBareAsync(RepoConfiguration confi | |||
String outputFolderName, LocalDateTime sinceDate) throws GitCloneException { | |||
try { | |||
return CommandRunner.runCommandAsync(rootPath, | |||
getCloneShallowBareCommand(config, outputFolderName, sinceDate)); | |||
getCloneShallowBareCommand(config, outputFolderName, sinceDate)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tests for GitClone seems lacking compared to the other Git classes. Perhaps we could figure out a way to test the various clone variations (in a separate issue).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a strange coincidence, I did voice the same thought some time back and the response is here #1562 (comment) under point 2.
I think in general, cloning is quite expensive so they can be done together with the system tests. If the system tests work, then the cloning likely works with it. There is an argument to be made for cloneFromBareAndUpdateBranch
which is a local-to-local clone done while analyzing but I'm not sure how we would go about testing it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes sense to test these with the system tests, since the issues seem to be with system-specific quirks (although I'm not sure how much of GitClone is covered by the systemtests). I think the linked comment is probably right about tests in that we can only go to the extent of ensuring that the methods return the correct Strings and throw the right exceptions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
The following links are for previewing this pull request:
|
Fixes #1682
Currently, clone output paths are not quoted. The issue is rare as it can only occur against local repositories where the final directory contains a space.
This PR also includes changes to the existing
GitClone::cloneFromBareAndUpdateBranch
method. It used to be the only method that constructs its own git command without the use of a helper private method which is likely why it was missed and none of its directories are quoted. This change aims to standardize the format between different git clone methods withjava -jar RepoSense.jar
). As of this PR, thecloneFromBareAndUpdateBranch
is the only one that does not run the command from the current directory. This is the result of [#1546] RepoCloner: fix local repos relative pathing and spaces #1562. Before that, commands were run from the cloned repo directory but the commands themselves were constructed as if they were in the working directory. This caused issues when relative pathing was used. The fix changed all but one of the use ofgit clone
to start from the working directory. Only thecloneFromBareAndUpdateBranch
method was not changed as it seemed to break other things.Commit message: