pijul_org / pijul

#60 suggested alternative name to 'delete-branch' command

Opened by hard_lines, on April 22, 2017
hard_lines commented on April 22, 2017

"delete-branch" is both (unnecessarily) long and inelegant as a name for the command.\r + perhaps "prune" would be a better alternative, as it is both short + fits well with the use of the metaphors of tree and branch.

lthms commented on April 23, 2017

I am not convinced that metaphoric names are good for a cli tool.\r + \r + I think a better solution should be to group all the branch related subcommands under the pijul branch call, either pijul branch [new|delete|switch] or [--new|--delete|--switch].

hard_lines commented on April 24, 2017

In retrospect, I concur. Although'checkout' is familiar to users of git etc. It is not the most intuitive name to use for the command when considering new users of vcs. The use of 'fork' also adds extra commands that a new user would have to learn. Your suggestion requires the user to only learn one command namely 'branch', the subcommands would be obvious and easy to remember for any user; experienced or rookie.

hard_lines commented on April 26, 2017

perhaps it would be good to go for the following:\r+ \r + pijul branch [new|delete|switch|list]

pointfree commented on October 15, 2017

@lthms, I like pijul branch [new|delete|switch|list]\r + \r + @hard_lines I agree with you on checkout, we have a great opportunity here to make a truely composable and orthogonal ui so we should not be bound by the "unfixable mistakes" of other vcs'.\r + \r + I was also thinking that `pijul show-dependencies is kind of long for a subcommand name. I think hyphenated names are codesmell, they are a sign that something needs to be broken down further. How about subcommands broken down along subject-predicate-object triples (aka resource-property-value):\r + \r + # |-------sub------------------| |-pred-||-obj----------------|\r + # |-sub-| |-pred-| |-obj-| \r + pijul master patches <hash>,... show files contents \r + pijul master patches <hash>,... show patches dependencies\r + pijul master patches <hash>,... files <path>,... show dependencies\r + pijul master patches list patches # pijul log\r + pijul master files <path>,... show files contents \r + pijul master files <path>,... show list patches \r + pijul master files <path>,... list files patches # pijul log <path>\r + pijul master patches <hash>,... list files <path>,... # what files did the selected patches involve?\r + pijul master patches list files # pijul ls\r + pijul master patches add files <path>,... # pijul add\r + pijul master patches select add remove <path>,... #\r + \r +

  • I like to put parameters that change the least closest to the left side and parameters that change the most further to the right side where it is easiest to tack on additional arguments in an interactive session.\r + \r +
  • Some combinations of commands might not make sense. Rather than inserting stubs or throwing errors there, I would tweak the meaning of the primitives so that there would be no non-sensical combinations.\r + \r +
  • I would give some combinations their own name/pattern forming a higher level subcommand. For example:\r + \r + log as list patches then try pijul files &lt;path&gt; log or pijul log (pijul uses patches all as the default subject subcommand.\r + \r + ls as list files then try pijul ls aka pijul patches ls.\r + \r +
  • choose sensible defaults for when arguments or subcommands are omitted. pijul patches all &lt;predicate&gt; &lt;object&gt; == pijul '*' &lt;predicate&gt; &lt;object&gt;\r + \r +
  • Make new subcommands with pijul &lt;subject&gt; &lt;predicate&gt; &lt;object&gt; aka pijul &lt;subject&gt; &lt;predicate&gt; &lt;object&gt; (notice that every command is a triple composed of three other triples)\r + \r +
  • Make default subcommands by defining some triples and leaving others to be "defined" at runtime so to speak.\r + \r + pijul list files all\r + pijul list files ''\r + pijul ls list files\r + \r + Now, you can invoke pijul ls with or without arguments. If you invoke pijul ls without arguments it will match pijul ls list files, then, pijul ls list files won't match pijul list files '*' because you didn't provide a parameter beside ls so list files will match pijul list files all behind that.\r + \r + pijul ls <path>\r + \r + These patterns are to matched from newest to oldest (this is hyperstatic scoping, a kind of short-circuit evaluation for matching definitions).\r + \r + define the help commands:\r + \r + pijul help '' ''\r + pijul help show intro # all names are specified here and definition is most recent...\r + pijul # ...therefore invoking pijul without arguments will show the intro help topic.\r + \r + Invoking a command with unrecognized triple names will define those triple names for the duration of the command if it's some transient query command. If they are not a transient commands such as pijul upstream patches pointfree@nest.pijul.org:pijul_org/pijul; pijul upstream pull ask; pijul upstream pull '*' then pijul upstream pull 8zNwpYfaNFwAVuWvGJAemAWZM2nPoBugf5EbzZrdW8heYhp7NbsHUMAiU39k1j8QYEHdcUMdacVA3xCqtWavtQCq will define the patch 8zNwpYfaNFwAVuWvGJAemAWZM2nPoBugf5EbzZrdW8heYhp7NbsHUMAiU39k1j8QYEHdcUMdacVA3xCqtWavtQCq until you revert it because revert will define an inverse that masks the effect of that patch.\r+ \r +
  • I would approach implementing a composable ui by figuring out what primitives we might want or want to eliminate. I would then enumerate all possible subcommand triples.\r + \r +
  • For some of these triples we would want a special hardcoded implementation instead of literally composing them. The user might still think they are composing different subcommands even though they are actually using a better performing lumped implementation in the backend.\r + \r +
  • Third party plugin subcommands? Miscellaneous Unix commands as triples? That would be fun. I would prefer that to putting in hooks everywhere.\r + \r +
  • This ui is inspired by graph databases and also the Forth programming languages' approach to scoping. It may be a good fit for operating on the pijul graph at a low level if needed.\r + \r +
  • So yeah. Apologies I got a little carried away here. Needs some copyediting. Anyway, I would start with hard coded implementations of various subcommand combinations that might be useful and then start factoring out common pieces. That makes implementation more approachable and would perform well in contrast to parsing outputs, etc.
pointfree commented on October 15, 2017

You may have noticed that I included commands/definitions with more than three parameters like this one:\r + \r + pijul master files <path>,... show list patches\r + \r + Accumulating wildcards from other definitions gives a way to nest multiple triples in a single command line.

pmeunier commented on December 13, 2018

Thanks for raising that issue, even if it's quite old and I haven't replied much until now.\r + I just unilaterally decided to rename both delete-branch to prune, and show-dependencies to dependencies (aliased to deps). Thanks for all your suggestions and comments!