Add variable export mode

[alerque]

Extracted from #248...

There are some cases where instead of opening a new shell using vcsh enter ... it would actually be more useful to setup the current shell for use with Git tooling connected to a VCSH repository.

Since it's impossible to manipulate the parent process environment the implementation for this would have to do what everybody else does: dump code that can be evaled in the parent shell. Usage might look like:

$ eval $(vcsh export repo_name)

This could be wrapped in a shell function in the user's profile something like this:

vcsh-switch () {
  eval $(vcsh export $1)
}

To be used thus:

$ vcsh-switch repo_name

[RichiH]

Historical context:

The earliest versions of vcsh allowed both being sourced and executed; which broke down trying to support Bash and Zsh at once. The overhead of execution is neglible.

vcsh export was "reserved" for putting vcsh repos onto remote machines which didn't have it installed, and vcsh import the inverse of taking in changes from remote machines. Not sure if the use case makes much sense any more. Would vcsh expose-work-tree or something make sense?

[alerque]

I saw #75 re vcsh export after this. The name isn't that important, something like vcsh dump_vars might be better anyway.

The bash vs. zsh vs. foo thing should be a pretty much non issue if all that is involved is exporting some ENV vars. Whatever is being done along those lines already works across shells.

I'll have to review my own old use case for this. I know I scripted around it and it might not be important, but I do remember this being a pain point and thought it worth extracting from the other issue and reviewing on its own.

[RichiH]

Aye, NP. So let's keep export free and use something else; even if there's no active use case for you or me, exposing vars might still be useful and is easy enough to do.

As to Zsh/Bash/Posix: The early versions could be sourced and executed with the same codebase. Took some hacks, but was fun while it lasted :p