Think through 'work stash'.

[zanerock]

Overview

The use case is:

1. I have some uncommitted changes in the current unit of work. For instance: dev runs across bug and fixes it, but it's not really part of the current unit of work.
2. You want to save this work somewhere, then continue on with what you're doing.

Option 1: Create a task and new unit of work all in one go. Commit the changes to the new unit of work, then switch back to the current unit of work:

liq work stash --overview "Foo." "Bug"

Where '--overview' is required in this case and the arg is the task summary and used in the branch descriptor. Would also like to support '--task', ideally with multiple '--task' support (probably change to setSimpleOpts).

Option 2: Create a new local unit of work without any associated issue. This can't be submitted, but it could be merged to some other work. This would be useful in the case where the bug isn't related to what I'm doing now, but maybe is related to something else I'm working on.

liq work stash --no-task "Bug"

In this case, '--overview' is not required (or used?) and '--task' is not allowed.

Deliverables

• Look into liq work merge. It should be operating on the work unit level (to match with all this). E.g., merging from Work Unit A to B would require that for every project involved with A with changes, that project is also involved with B.
• Can we think of a better name? 'Stash' does collide with the git command.
• Should this require there are changes to be committed? Seems like it should work fine as a way to create a 'named bookmark' at the current Work Unit collective HEADs as well. However, in that case, it wouldn't make sense to create a by default... so maybe have liq work stash and liq work bookmark that share much of the same code, but match different use cases and preconditions?
• I think it's actually 'bookmarks'
• And stashes? But then aren't they just units of work, so 'stash' is a way to create a unit of work... right?