2 ms·
The idea you somehow NEED to learn all the commands as a reason why it's hard is crazy. Adding HighFlow on top will just add more commands because inevitably t
by philipwhiuk 4y ago
The idea you somehow NEED to learn all the commands as a reason why it's hard is crazy.
Adding HighFlow on top will just add more commands because inevitably there'll be a point where some HighFlow abstraction fails and you have to go to Git anyway to fix it.
Also I can see that HighFlux runs as a daemon. That seems sub-optimal - sucking up my CPU all the time on the off chance I want to code something is not great.
It doesn't seem like HighFlow supports actual remote repositories except GitHub. Which is the entire point of a distributed version control system - to be distributed.
I think HighFlux is designed to solve a very limited subset of Git's usage and so they've stripped out a lot of useful commands they don't use and so they can ship a product.
But in the real world people will need this and their simple vision will crumble back to the complexity of Git (or close).
- guytv 4y agoOne of the developers of HighFlux here. The deamon is written in rust and was designed and written to have a minimal CPU+Memory footprint. > I think HighFlux is designed to solve a very limited subset of Git's usage and so they've stripped out a lot of useful commands they don't use and so they can ship a product. Yes and no. No - once you correlate the user intent with the git commands, you discover that to accomplish one "intent," such as "start working on a feature," - you only need one CLI/UI command: "create WIP". So naturally, many git commands are bundled into one user intent. Yes - true - we're just starting, so naturally focusing on the most used scenarios, gradually covering more and more cases as we progress. The nice thing is that HighFlux is not only compatible with git but also inter-operable with it, so you can always "go back to git" - until we cover all of the scenarios.
- deleted 4y ago[deleted]