You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original question was about proenv installs into .proenv and cleaning the .git directory when used as a template repo
Why not fetch directly into .proenv? Why the template approach? Or is there a better way?
Answers
The temporary hooks/post-checkout script MUST be accessible at clone time (the only template justification)
The rest of the proenv artifacts moved out or cleaned out of the .git repository effectively is like installing proenv for the project which might be preferred to installing it globally.
The text was updated successfully, but these errors were encountered:
Do we want proenv installed somewhere with its bin/ directory accessible on the PATH? What will it buy us?
Answers
The ONLY benefit of global installation is this simple proenv-clone script being on the system path to clone new repositories while outside of a proenv project's folder
May explicit use of curl be better? Not necessarily.
Why elevate privileges to install onto the system? Instead, if the installation does occur to allow for us outside of a project repository directory, then it should be in the user's ${HOME}/.local/bin.
This is a valid option especially if its use is overridden by a more specific version kept in the proenv project's .proenv/bin
Version information should be stored both for the project and for user installation
Installation for the user should use a different script rather than use proenv-clone
akarasulu
changed the title
Clean up junk remaining in .git
Project vs User vs System level installation
Jun 6, 2022
Why not fetch directly into .proenv? Why the template approach? Or is there a better way?
Answers
hooks/post-checkout
script MUST be accessible at clone time (the only template justification)The text was updated successfully, but these errors were encountered: