D 2019-09-27T11:50:36.109
L branch/double-dash-flag
N text/x-markdown
P 8c84b2a79575026b954a5abe2ad288751bc892e83fa425eadf46b6a01730c19d
U stephan
W 2983
The `double-dash-flag` branch aims to add support for the conventional interpretation of a `--` flag: all arguments after the first instance of `--` are to be treated as non-flag arguments (e.g. file/wiki/branch/whatever names).
This feature request is from: <https://fossil-scm.org/forum/forumpost/64acc6b653>
The implementation is not *100%* compliant with POSIX/Unix conventions because it cannot be without *Breaking Stuff*, but it "should" be close enough to be useful/conventional for the contexts where using `--` makes sense in Fossil. For example, `uv add` treats a filename of `-` as `stdin` by default (and has valid use cases enabled by that), and `--` could be used to make `uv add` treat `-` as a filename ([that's the original use case for which conventional `--` support was proposed](https://www.fossil-scm.org/forum/forumpost/d6fa7422db)).
Fossil's [historical handling of `--` is really weird](/artifact?ln=925-928&name=a35b33b329ab2038): the *first* time `find_option()` encounters `--`, it *removes* that flag and stops processing arguments. Subsequent calls to `find_option()` then never see `--` and thus treat all arguments as potential flags (even those after the prior position of `--`). Since that behaviour was never useful, and potentially confusing, it is unexpected that the changes made in this branch will break any historical usage of the CLI commands.
The placement of the `--` flag is significant, of course::
fossil branch new FOO BAR --private
If a user insisted on having a branch named `-` and did:
fossil branch new -- - BAR --private
then `--private` would be seen as a non-flag argument. Anyone using `--` for this purpose would necessarily be using a newer version of fossil where `--` has well-defined semantics, and therefore would not place `--private` after `--`.
Commands which accept a filename as the value of a flag are unaffected by these changes, provided the flag comes before `--`:
fossil foo -R - -- -a -b -c
Would (both before and after this change) treat `-` as a repository file name, but this change will cause the subsequent `-a -b -c` flags to be interpreted as non-flags. The current (trunk, as of this writing) interpretation of `-a -b -c`, because of the "one-time-swallowing" of `--`, depends on what order those flags were checked for via `find_option()`.
# (ONGOING) List of commands/subcommands extended to support `--`
(Please keep this list alphabetized by command/subcommand name.)
* `branch new`: you might recall Johnny Cash's song *The Branch Named --Sue*.
* `uv add`: unconditionally reads in its contents via `blob_read_from_file()`, which internally treats `-` as stdin. Thus adding `--` support here requires (A) that `uv add` know that `--` was provided, (B) that `--` was provided *before* `-`, and (C) special-casing `-` in that case (only) to not read from `stdin`. Hopefully we don't have many such cases.
* `uv cat | edit | export | rm`
Z c78b1b5518a5d0df29ade07dc67db437