lib/git return type audit

Many of our functions in lib/git have the return type Promise<void>. This makes it difficult for callers to know if the function succeeded or failed (unless it throws an error).

This is particularly important for cases like https://github.com/desktop/desktop/blob/aa79543d8d373763dccc7a51a26e277db1d5960c/app/src/lib/stores/app-store.ts#L3134 where the merge may fail (for expected reasons) be we need to have that information as the caller.

Goal

Determine the appropriate return type for each of these functions.

Akin to https://github.com/desktop/desktop/issues/5923, it may be appropriate for some functions to return a sha or some other information on success, but at many of these functions should at least return true or a generic “success” type to indicate to the caller that nothing went wrong. (we should have at the very least exit codes from git() for all of these functions to judge that by.)

Functions to Audit

(these are all functions with the return type Promise<void> in lib/git)

• createMergeCommit
• setRemoteURL
• applyPatchToIndex
• renameBranch
• checkoutBranch
• checkoutPaths
• clone
• setGlobalConfigValue
• writeGitDescription
• fetchRefspec
• fetch
• saveGitIgnore
• initGitRepository
• installGlobalLFSFilters
• abortMerge
• pull
• push
• revertCommit
• unstageAllFiles
• resetSubmodulePaths
• stageFiles
• updateRef

Notes

Any PRs that change these return types should also include tests that verify those types are returned in the right situations so we don’t inadvertently cause regressions.

cc @shiftkey, as well as @say25 for additional thoughts since they’ve done prior work like this

[shiftkey]

@outofambit @say25 I have a few questions about this but am swamped with 1.6 stuff. Please hang on a bit before we dive into PRs.

[outofambit]

this might be worth revisiting (post 1.7.0) since we experienced some pain (and lost time debugging) over in #7474, due to returning Promise<void> into gitStore.performFailableGitOperation

i made a quick fix by returning true at the end of checkout which might be a decent first iteration here just to alleviate this potential gotcha.