Skip to content
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

Conversation

chan-j-d
Copy link
Contributor

@chan-j-d chan-j-d commented Feb 21, 2022

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 with

  1. The method handling the logic of setting up and running the command has to create its own 'command constructor' method to create the String. This way, it is easy to standardize changes to the command formats by looking at these methods without having to see what they are used for.
  2. Defaulting the directory in which the commands are run to the current directory (location the user invokes java -jar RepoSense.jar). As of this PR, the cloneFromBareAndUpdateBranch 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 of git clone to start from the working directory. Only the cloneFromBareAndUpdateBranch method was not changed as it seemed to break other things.

Commit message:

Output directories are not quoted which can lead to errors. The 
GitClone::cloneFromBareAndUpdateBranch method is also not standardized
to match other clone methods which always run from the working
directory. This can be difficult to maintain.

Let’s fix the issue of spaces in repo directory causing clone failure
and standardize the cloneFromBareAndUpdateBranch method.

@chan-j-d chan-j-d requested a review from a team February 24, 2022 05:10
@chan-j-d chan-j-d marked this pull request as ready for review February 24, 2022 05:11
@@ -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);
Copy link
Contributor

@gok99 gok99 Mar 5, 2022

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.

Copy link
Contributor Author

@chan-j-d chan-j-d Mar 5, 2022

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:

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));
Copy link
Contributor

@gok99 gok99 Mar 5, 2022

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).

Copy link
Contributor Author

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.

Copy link
Contributor

@gok99 gok99 Mar 5, 2022

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.

Copy link
Contributor

@gok99 gok99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Copy link
Member

@dcshzj dcshzj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@dcshzj dcshzj merged commit 7e4d6c0 into reposense:master Mar 25, 2022
@github-actions
Copy link
Contributor

The following links are for previewing this pull request:

@chan-j-d chan-j-d deleted the 1682-space-in-local-repo-causes-cloning-exception branch March 25, 2022 11:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Space in local repo final directory causes cloning exception
5 participants