All subcommands can use the flag package to describe their options about dgit HOT 8 CLOSED

I've added an example for two aliased flags in #48. When converting other aliased flags it should be possible to extract a more abstract structure and functions to make reuse easier.

@driusan do you have an example in the code of order sensitivity for flags? I would like to have a look at these cases so that I can consider them in the design.

from dgit.

I suspect someone could also fully implement fix t0007-git-var.sh pretty quickly. There's only 7 test cases, and most of them just fail because the git var command isn't implemented at all (but I think the functionality of git var is a subset of git config, which is implemented..)

from dgit.

We already have hacks for aliases by setting multiple flags, and then or'ing them to get the result (or checking if either are non-default values for int/strings/etc), but if there's a more robust way to do it (or one that groups them together in output), we should do it.

But even with all that, we're still missing order sensitivity for a few commands.

from dgit.

I don't know if there's any we currently support, but rev-list has a --not option that inverts the meaning of commits until the next --not

from dgit.

I have open PR #52 with proposed changes for this.

from dgit.

If we just want to put the infrastructure in place so that we can run t0000-basic.sh once we've fixed those four, for now we could just run one of the test cases that spuriously report passing for dgit like t0006-date.sh.

(We could also consider conditionally running the whole suite based on an environment variable, and including that version in an allowed_failure build.)

from dgit.

I have raised PR #58 to add the git var command and the official test suite.

from dgit.

update-index is another case where the flags are context sensitive. For instance, the setup of t1001-read-tree-m-2way.sh calls git update-index --add frotz bozbar --force-remove rezrov

from dgit.