Docs and customised paths #69
Conversation
… the Branchoutfile.
… and multiline code blocks. Triple must start and end on its own lines before and after the block. Single is usually used inline in the middle of text. It is an error to use triple inline in text and the local syntax highlighting reflects that.
…ich may or may not be possible at this time. Intent is for Mike to add commits on top of this one to fill gaps and correct things and for me to rebase -i clean it up once we're where we need to be. Please don't amend this and force push.
| @@ -97,6 +97,24 @@ BRANCHOUT_NAME=shorter-name | |||
|
|
|||
| to the Branchoutfile and ideally use the same value as the optionalDirName during branchout init. | |||
|
|
|||
| ### Personal customisation | |||
|
|
|||
| Sometimes the branchout defaults don't work for a particular scenario even though they do work for most of your colleagues. | |||
There was a problem hiding this comment.
see this is the problem... they should work for everyone or no one... there aren't really special cases for people although the org might be special
There was a problem hiding this comment.
Take a step back. What's important about this tool is NOT conformity and control of author over the world.
What's important about this tool is:
- Documenting a set of repos for a particular purpose within an organisation or for the public
- Efficiently managing large numbers of repos in a clean/easy way
- Consistent tooling for building projects with separated/isolated software repos
- Helper tooling for common things done on sets of projects (eg consistent git email and sshCommand config set on clone, may not be available yet, but I'm keen to add it)
- Consistent structure within a set of repos (currently only one style supported, but a few others have been brewing in my head for a while, keen to implement and use)
And all of that stuff is GREAT and a good reason for me to burn my personal time on this in the coming months, happy to become contributor number two to your project/great idea! :-D
Where on your disk those two roots are is NOT important, not even when you share a path to a colleague, unless they're of below average intelligence. The only part of the path that is key to consistency/understanding should be the BRANCHOUT_NAME within those two root directories, wherever they are. Typically paths I give to colleagues are in the context of the repo that the discussion is about, eg src/main/java/ or whatever, not full absolute paths that may mean nothing on their disparate operating systems anyway.
On my machine ~/ is cleared out every night at 4am against a whitelist so I had to update that whitelist to add two more entries and every time I ls -al ~/ I see ~20% extra stuff that I don't want to. My personal structure after this is changed will be:
~/repos/branchoutRoots
and
~/repos/branchout/cacheAndSettingsRoots/
then it'll all be in one place, nice and handy right next to my not-yet-managed-by-branchout structures that I'd LOVE to port over :-D
I've told you before, I love this project. And I've also told you, it doesn't 100% work for me, yet. This is a step in the right direction that will also help many others with unpleasant usage situations to deal with get the best out of the tool in environments that they don't fully control.
README.md
Outdated
|
|
||
| ``` | ||
| ~/.config/Branchoutrc? | ||
| ${BRANCHOUT_BASE}/.branchoutrc |
There was a problem hiding this comment.
are you thinking a common place like the metarepo? i guess that would work
BRANCHOUT_PROJECTION_DIRECTORY
There was a problem hiding this comment.
i guess it could be absolute but that just is hard if you have multiple platforms
There was a problem hiding this comment.
Good question, both of these two lines were for you to confirm/rewrite in a way that makes sense. They were just guesses.
I'll add a glossary from the source code, maybe in a different file? And we can get on the same page terminology/jargon wise there.
README.md
Outdated
| In cases like these you can use the following two files to ???? | ||
|
|
||
| ``` | ||
| ~/.config/Branchoutrc? |
| ``` | ||
| #### Moving the branchout projects base dir | ||
|
|
||
| To set the root of where branchout initialises branchout repos do XXX |
There was a problem hiding this comment.
set BRANCHOUT_PROJECTS_DIRECTORY in ~/.config/branchoutrc
There was a problem hiding this comment.
@stickycode Is this true? Where I saw this used it was used on top of ${HOME} and it would be perfectly reasonable to put it on another drive mounted under for example /code or whatever that's outside ~/ - one such reason that I've hit in the past is limited path names in ubuntu with encrypted home functionality. I had to have my repos outside of ~/ for that reason.
Do we need a new variable that overrides both this and the base path being $HOME or just a wrapper layer around home that uses home as a default and lets you override it to eg / or wherever else you want it?
|
|
||
| #### Moving the branchout caching base dir | ||
|
|
||
| To set the root of where branchout stores project specific caches and settings/credentials do YYY |
There was a problem hiding this comment.
i guess this should be similar BRANCHOUT_STATES_DIRECTORY in ~/.config/branchoutrc
There was a problem hiding this comment.
See other comments above, if we keep this relative to the current $HOME and then just move the base of both that could be good enough, or might be better to have the two base values also be separate?
|
@stickycode what is the purpose of the branchoutrc in |
… file layering and remove question mark from branchoutrc and replace capital B with b and correct var name for the other branchoutrc and comment on that.
…d modified as necessary to suit any changes made.
|
Outcome on discussions about this from earlier today: The change will be from a single partially configurable option (I feel like we should keep supporting this provided both aren't specified which would be an error) to two overrides both of which are full paths not relative or composite. When I'm clear of other higher priority work I'll pick this up again and move it forward. |
Forgot about this, but probably still a valid question if it ever was one. |
|
The one in .config is global while the one in the branchout state folder is
for a subset of your projections that share caches
…On Mon, 28 Jun 2021, 21:16 Fred Cooke, ***@***.***> wrote:
@stickycode <https://github.com/stickycode> what is the purpose of the
branchoutrc in ${BRANCHOUT_STATE}/as opposed to the one in ~/.config/ ?
Forgot about this, but probably still a valid question if it ever was one.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#69 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAG4GFE77HZBMN62YU7H6SLTVA4VBANCNFSM43NTYGQQ>
.
|
|
Okay, that's fair enough. So I take it that the settings are in this order: Defaults in scripts Is that right? If not, what is it doing? |
|
That is correct
…On Mon, 28 Jun 2021, 21:25 Fred Cooke, ***@***.***> wrote:
Okay, that's fair enough. So I take it that the settings are in this order:
Defaults in scripts
Global overrides defaults
Local overrides global
Is that right? If not, what is it doing?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#69 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAG4GFF7J3SL5MCOSRXJPETTVA5YHANCNFSM43NTYGQQ>
.
|
First 3 commits should be good improvements. Last one is a work in progress and clearly marked as such. Please amend the work in the last one to fill in the gaps and make it accurate about what's possible now with those two files/what you can do with those two files, and any further existing examples. Then we can amend the docs and tests to cover new scenarios that aren't possible and then implement those. Then final review and merge. Not using broken Microsoft PR draft feature, assigned to me, will reassign once I feel it's ready.