StreakyCobra / gws

Colorful KISS helper for git workspaces
https://streakycobra.github.io/gws/
MIT License
235 stars 22 forks source link

Enhancements: verbosity, flat, versions, contradictions #24

Closed ZvikaZ closed 7 years ago

ZvikaZ commented 8 years ago

Few possible enhancements:

1: Currently GWS is very verbose. It's nice, but if there are many repos, and it's called as part of other script, it can be too verbose... I think it's better to have 3 level of verbosities:

The user can have default verbosity, set either in an environment variable, or in ~/.gws.rc file; and the verbosity can also be changed in every run of the script with a run time flag.

2: "Flatten recursive" tree support. Suppose we have a repos tree, like this:


a
├── b
└── c
    └── d

Where 'a' is top repo, which reuses repos 'b' and 'c'. Repo 'c' in turn, reuses repo 'd'. I'd like to have all repos 'flat' under the top repo, so effectively it would be treated like this:

a
├── b
├── c
└── d

a's .project file doesn't mention 'd' explicitly, but all GWS commands, from everywhere in this tree, will treat 'd' as 'brother' of 'b', and it will be located directly under 'a'.

This behaviour should not be under user configuration (opposed to verbosity configuration) but a property defined in the .project file.

Maybe something like this: lib/tools | https://github.com/nice/tools.git | flat - would treat everything mentioned in tools' .project as if it was mentioned in my .project file.

3: Versions support - the ability to specify that some repo should be in a specific version (or branch, or tag).

I know it can be modified in each repo individually, but I'd like to make that info (sometimes) official, so it can be part of the deployment. Specific version of .projects.gws brings specific version of some repo.

lib/tools | https://github.com/nice/tools.git | release_013 - would fetch tools repo, and take the tag 'release_013' This will probably make use of gws update to update the repo to that version.

4: An interesting complication is the combination of my suggestions 2 & 3. Check this tree:

a
├── b
└── c
    └── g
        └── b

What happens if we flatten this tree, and 'a' requests 'b' to be 'r_013' while 'g' requests 'b' to be 'r_014'? There are many possibilities here. I think the best solution would be to issue a contradiction warning, and let the requirement of the higher repo in the hierrarchy to win. (i.e., 'c' will win 'g' (if it contradict), and 'a' will win 'c' and 'g')

StreakyCobra commented 8 years ago

Thanks for taking time to write this! I'll consider it when, and if, I continue to work on this project :-)

emlun commented 7 years ago

Thank you for your input!

  1. This will be somewhat alleviated with the new --hide-clean command line option introduced by #30. Does that cover some of your needs?
  2. I'm afraid I also don't have the time or will to develop such a feature in bash. It would have to be in a reboot in a more capable language.
  3. This has been discussed in #15, and it would be difficult to squeeze the setting into .projects.gws without breaking existing project files. It's probably possible, but it would likely require some awkward fidgeting to parse correctly. Again, I'm afraid I can't invest the time to work out how to do it without breakage - but please do submit a PR if you find a way to do it.
  4. (Irrelevant without 2.)
StreakyCobra commented 7 years ago

it would be difficult to squeeze the setting into .projects.gws without breaking existing project files

The format started as a simple list, then have been hacked to fit the need of different remotes, it is far from optimal. Gws is still in <1.0, so breaking the file format could be an option if needed.

Someone once suggested to use a standard file format, like YAML, instead of this custom format. This would offer syntax coloration in text editors, and would allow to parse it easily in other languages. I like the idea, and there are some code to parse YAML from bash [1] [2].

I'm just saying this FYI, so you have this in a corner of your mind if the need arises :-)

emlun commented 7 years ago

Reviewing this again, I also think git submodules already solve (3) well enough. Migrating to YAML or something similar would be nice of course, but I'd say both of these are out of scope for this incarnation of gws.