Require Absolute paths in branch util combinators from the root branch #3817
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
During #3798 @rlmark and I were working on some stuff and there was some confusion about what sort of
Path
needed to be passed to themakeDelete
combinator; It previously accepts just aPath
. The logic requires that this be relative to the root of the codebase, but it's pretty easy to accidentally pass a Path relative to the current location instead 馃槵 , and it wasn't clear to her as a new contributor which sort of path to pass.This changes all of the MonadUtils combinators to explicitly accept an Absolute split so it's clear where the path must be rooted.
As you'll see in the diff, in most spots we already had an absolute path anyways and were just converting before passing it it, might as well convert it after passing it in and make things a bit clearer and more type-safe.
Implementation notes
make*
combinators in BranchUtil to accept and return any flavour of Path in their splits. This is polymorphic over the path type because if you're usingBranch.stepMany
rather thanCli.stepMany
you'll need a Path, since it may not be relative to the root.Cli.stepMany
-style combinators, since these are all going to be rooted at the root of the codebase.Test coverage
Existing transcripts should be sufficient.