Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: git/git
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: 278c251147
Choose a base ref
...
head repository: git/git
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: fb0dc3bac1
Choose a head ref
  • 2 commits
  • 3 files changed
  • 1 contributor

Commits on Apr 10, 2018

  1. builtin/config.c: treat type specifiers singularly

    Internally, we represent `git config`'s type specifiers as a bitset
    using OPT_BIT. 'bool' is 1<<0, 'int' is 1<<1, and so on. This technique
    allows for the representation of multiple type specifiers in the `int
    types` field, but this multi-representation is left unused.
    
    In fact, `git config` will not accept multiple type specifiers at a
    time, as indicated by:
    
      $ git config --int --bool some.section
      error: only one type at a time.
    
    This patch uses `OPT_SET_INT` to prefer the _last_ mentioned type
    specifier, so that the above command would instead be valid, and a
    synonym of:
    
      $ git config --bool some.section
    
    This change is motivated by two urges: (1) it does not make sense to
    represent a singular type specifier internally as a bitset, only to
    complain when there are multiple bits in the set. `OPT_SET_INT` is more
    well-suited to this task than `OPT_BIT` is. (2) a future patch will
    introduce `--type=<type>`, and we would like not to complain in the
    following situation:
    
      $ git config --int --type=int
    
    Signed-off-by: Taylor Blau <[email protected]>
    Signed-off-by: Junio C Hamano <[email protected]>
    ttaylorr authored and gitster committed Apr 10, 2018
    Configuration menu
    Copy the full SHA
    0a8950b View commit details
    Browse the repository at this point in the history

Commits on Apr 19, 2018

  1. builtin/config.c: support --type=<type> as preferred alias for `--<…

    …type>`
    
    `git config` has long allowed the ability for callers to provide a 'type
    specifier', which instructs `git config` to (1) ensure that incoming
    values can be interpreted as that type, and (2) that outgoing values are
    canonicalized under that type.
    
    In another series, we propose to extend this functionality with
    `--type=color` and `--default` to replace `--get-color`.
    
    However, we traditionally use `--color` to mean "colorize this output",
    instead of "this value should be treated as a color".
    
    Currently, `git config` does not support this kind of colorization, but
    we should be careful to avoid squatting on this option too soon, so that
    `git config` can support `--color` (in the traditional sense) in the
    future, if that is desired.
    
    In this patch, we support `--type=<int|bool|bool-or-int|...>` in
    addition to `--int`, `--bool`, and etc. This allows the aforementioned
    upcoming patch to support querying a color value with a default via
    `--type=color --default=...`, without squandering `--color`.
    
    We retain the historic behavior of complaining when multiple,
    legacy-style `--<type>` flags are given, as well as extend this to
    conflicting new-style `--type=<type>` flags. `--int --type=int` (and its
    commutative pair) does not complain, but `--bool --type=int` (and its
    commutative pair) does.
    
    Signed-off-by: Taylor Blau <[email protected]>
    Signed-off-by: Junio C Hamano <[email protected]>
    ttaylorr authored and gitster committed Apr 19, 2018
    Configuration menu
    Copy the full SHA
    fb0dc3b View commit details
    Browse the repository at this point in the history
Loading