Skip to content

Implicit specification of the target compstate #6

@PeterJCLaw

Description

@PeterJCLaw

Now that the command line tools have been in use a while, I've often found it a little frustrating that I always need to explicitly specify the path to the compstate to operate on. On the one hand, I enjoy the explicitness of it, however when trying to deploy changes in a hurry it can get a bit tiresome.

There's definitely an argument that being explicit when deploying under pressure, however I often end up editing a previous command anyway, so I'm not sure we're really gaining much.

I've also found myself sometimes needing to look up where in the positional arguments the compstate path should go. I think we're almost consistent on this, but not perfectly so.

I've therefore been wondering about whether we should instead take the approach which many other tools take -- of using the current directory as the determining factor. Like git and the sr inventory tools do, we might want to allow the user to be within a subfolder (rather than the repo root), however that's fairly easy thanks to git rev-parse --show-toplevel.

The main gotcha I see is that the compstates don't have a canonical this-is-a-compstate file we can look for to be sure that we're operating on a compstate (rather than some other git repo). Detection of this would be fairly important to avoid either confusing or badly training the user.

An alternative mechanism might be to allow the compstate to be specified by an environment variable. This could easily be set by the user upfront, however has the disadvantage that (aside from users modifying their $PS1 themselves) would be less visible than the current directory approach.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions