Should use less general envvar/alias/function names when possible to avoid collisions

[sljinlet]

I already had an extensive bash setup when I recently found OhMyBash and decided to try it. I had a number (4-5 so far) of my existing additions and tweaks break because of things that the OMB configuration defines or redefines that clash with my existing stuff.

The way I see it, there are two classes of problems here:

1. Arbitrary names, like all of the settings in the .bashrc file (ex: CASE_SENSITIVE), that could/should be named with a OMB-specific prefix (ex: OMB_CASE_INSENSITIVE) to avoid unnecessary collisions

2. User-facing names, like the "glb" alias in the git plugin.

I see no reason not to do a renaming pass to avoid case 1) as much as possible. I assume that this project is not just targeted at brand new bash users, but also at seasoned veterans like myself. Why not adopt some sort of "namespace" naming style that avoids collisions that won't affect the end user and will serve to clarify the purpose of the things so named even if they don't collide with something else.

In terms of 2), I think more care should be taken to avoid the unconditional setting of names that should be seen as likely candidates for collision with existing setups. I mentioned 'gbl' specifically because that one hit me. I have written my own git script and named it 'gbl'. It has nothing to do with "git blame". Even if it did, I'd want to keep its functionality rather than having it overridden by a trivial alias. In this case, I would suggest either providing a setting variable that allows a prefix to be prepended to all of the defined git aliases (which could default to the empty string), or offering a setting variable that would exclude many if not all of the git aliases from being defined, so that the git plugin would only provide truly novel functionality. As it is, I disabled the git plugin completely rather than have to think much about this specific problem, as I wasn't aware of anything useful that the OMB git plugin was giving me.

EDIT: removed wrong mensioning of issues - @Kreyren

[Kreyren]

Referencing #73 commits welcomed

[Kreyren]

CASE_SENSITIVE is fixed in 5a5488e

[Kreyren]

Please avoid referencing other issues that are seemingly not relevant

[Kreyren]

Assigned P2 since this is Code Quality which is beeing investigated atm.