DBLab 4.0 CLI design decision: "dblab branch list" - list of existing branches or new branch (named "list") creation?
Context: #362; Slack thread (internal)
dblab branch list
– should it create a branch named list or should it list all the branches?
"pros" for the option "to list existing branches"
- Pros:
- this would give us a unified way – the same behavior as we already have for
dblab clone list
- those who expect that this will list branches, won't suddenly create a new branch (this happened to me at least twice already, during testing)
- ... (anything else?)
- this would give us a unified way – the same behavior as we already have for
- Cons:
- it is not like Git behaves (
git branch list
, indeed, creates a new branch). If we claim Git-like behavior, it would be great to be as close as possible. If we think this is a strong point, then:- to have unified behavior for commands
dblab branch
,dblab clone
,dblab snapshot
, we probably need to redesign the other two – sodblab clone list
would also create a new clone? or would produce an error? - if we redesign
dblab clone
(we can do it in 4.0, since it is right time for non-backward-compatible changes), then how are we going to list clones/branches/snapshots?-
dblab branch --list
,dblab clone --list
,dblab snapshot --list
? - Or maybe
dblab branches
,dblab clones
,dblab snapshots
?
-
- to have unified behavior for commands
- ... (anything else?)
- worth also considering: #362
- it is not like Git behaves (
Edited by Nikolay Samokhvalov