Closed arxanas closed 2 years ago
Oops, the motivation was in the commit message:
This is useful for an invocation of
cargo flamegraph
(and also probably forcargo run
):cargo flamegraph --bin git-stack --root -- --working-directory <repo>
The corresponding option in Git is -C
.
Oh, thanks!
I'll look at this more on monday to decide what the semantics should be standalone and as a git subcommand.
Right now I'm leaning towards this being -C
and matching git's semantics (allowing multiple and doing path joins on them) but having it hidden as people will most likely be using it via git
. I also want to see how git passes state for other related path flags to subcommands, like --git-dir
, to make sure we respect them as well.
I suppose that if users can use -C
from Git itself, then it might be better to hide this option and/or rename it so that it's obvious that it's for testing, or use a different mechanism like environment variables, or just drop the feature altogether since its use is limited. (For git-branchless, I added a -C
flag primarily for testing with cargo run
, but it doesn't actually do the behavior when specifying the flag multiple times.)
Closing in favor of #197
Could you help me understand the motivation? I'm not seeing git implement this, so its not for parity.