Is it possible to avoid remove and clone submodule again every time we checking out?

[ainopara]

• carthage install method: [ ] .pkg, [✓] homebrew, [ ] source
• which carthage: /usr/local/bin/carthage
• carthage version: 0.31.2
• xcodebuild -version: Xcode 10.1 Build version 10B61
• Are you using --no-build? no
• Are you using --no-use-binaries? yes
• Are you using --use-submodules? no
• Are you using --cache-builds? yes
• Are you using --new-resolver? no

Cartfile

github "SnapKit/SnapKit" ~> 4.0
github "ReactiveX/RxSwift" ~> 4.0
github "RxSwiftCommunity/RxGesture" ~> 1.1.1
github "RxSwiftCommunity/RxDataSources" ~> 3.0

Carthage Output

N/A

** Command **

carthage bootstrap --platform iOS --no-use-binaries --cache-builds

Actual outcome

*** Checking out RxGesture at "1.2.1"
*** Checking out RxSwift at "4.4.0"
*** Checking out RxDataSources at "3.1.0"
*** Checking out SnapKit at "4.2.0"
<- Waiting here to clone RxSwift twice.
...... (Omitting other output not related to this issue)

Expected outcome
Carthage should complete check out phase immediately since nothing changed (Cartfile.resolved not changed) here. But in this example, both RxGesture and RxDataSources have a RxSwift submodule.
In CarthageKit/Git.swift we have:

Carthage/Source/CarthageKit/Git.swift

Lines 217 to 224 in 8dea448

	return SignalProducer<(), CarthageError> { () -> Result<(), CarthageError> in
	repositoryCheck("remove submodule checkout") {
	try FileManager.default.removeItem(at: submoduleDirectoryURL)
	}
	}
	.then(cloneRepository(submodule.url, workingDirectoryURL.appendingPathComponent(submodule.path), isBare: false))
	.then(checkoutSubmodule(submodule, submoduleDirectoryURL))
	.then(purgeGitDirectories)

This method remove submodule directory entirely and clone it again which seems not necessary.
This behavior is introduced in fe918b1 as a fix of #76
Can we optimize the solution by trying checkout submodule first and only when we failed to checkout the specific commit, we clone it again?

[mdiep]

PRs welcome. :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.