Ask HN: CLI design of import/export commands

[mlawren]

I'm developing a distributed project management tool with a command line interface. I have two commands relating to initially copying a project to/from a hub. The export command looks like this:

    prog export PROJECT HUB

This reads well when compared with the English "export this PROJECT to the HUB".

The import command could have the same order of arguments if I also want it to match with the English "Import the PROJECT from the HUB":

    prog import PROJECT HUB

There is possibly some value in having a consistent order with the two commands. An alternative however is to enable the importation of several projects (or even all) at once, by reversing the order of the arguments:

    prog import HUB [PROJECT-1 .. PROJECT-N]

English can also be massaged to work this way "Import from HUB all projects, or the following projects: PROJECT1-N". This also has the advantage that it is a similar order to the "git clone" command which has familiarity for software developers, although git is the last tool I will be modelling my interface on.

Which order would you prefer, and why?

[mlawren]

For some context of how these commands fit in with everything else, here is the overall command usage summary:

    prog help [COMMAND...]
    prog init [DIRECTORY]
    prog import HUB [PATHS...]
    prog new ITEM
        prog new project [PATH] [TITLE...]
        prog new task [PATH] [TITLE...]
        prog new issue [PATH] [TITLE...]
    prog list ITEMS
        prog list topics
        prog list projects
        prog list project-states PATH
        prog list task-states PATH
        prog list issue-states PATH
        prog list hubs
    prog show ID
    prog log [ID]
    prog comment ID
    prog drop ID
    prog push ID PATH [HUB]
    prog export PATH HUB
    prog sync [ID] [HUB]
    prog upgrade [DIRECTORY]
    prog sql STATEMENT...
    prog ALIAS

At the moment PATH is the way to reference a project.

[mlawren]

In fact, while I'm here, any other comments you have on the interface are also very welcome. Possible topics: Order of commands as printed here, or the names of the commands and/or arguments, order of the arguments, whether arguments should be optional or not, etc.

If you have ever been annoyed at an inconsistency in git, and wished you could have had a say when it was being designed, then now is your chance to possibly affect how this tool matches your ideals.

The tool is not yet anywhere near releasable, but will most like (A)GPL.