Skip to content

feat: git-bug configuration #63

Open
Open
feat: git-bug configuration#63
Labels
area/configurationRelates to git-bug configurationkind/featureRelates to a new featurepriority/important-longtermImportant over the long term, but may not be staffed and/or may require multiple releases

Description

@MichaelMure
MichaelMure
opened on Oct 7, 2018

@adamslc said:

What are your plans for a git bug config command? To start off the conversation, here is an incomplete list of things that might possibly need to be configured. Note that I'm not arguing that everything on this list should actually be implemented.

* Default remote
* Set of possible labels
* Possibly move `git bug bridge configure` under here?
* Default new bug and comment templates
* Keybindings in `termui`
* Author data specific to git bug. I'm not sure if this exists?

Also, I think that having connivance flags to update the config from other commands makes sense. In #62 I suggested using -d and --set-default in git bug push to get and set the default remote. I'm now convinced that those aren't the right flags to use (looks to much like delete), but I still think that this is important functionality. Perhaps mirroring git push and using -u and --set-upstream would makes sense.

Activity

  1. MichaelMure commented on Oct 7, 2018

    @MichaelMure
    MichaelMure
    on Oct 7, 2018
    ContributorAuthor

    @j-f1 said:

    Why not use the regular git config command and name the settings git-bug.foo?

  2. MichaelMure commented on Oct 7, 2018

    @MichaelMure
    MichaelMure
    on Oct 7, 2018
    ContributorAuthor

    @adamslc said:

    For some settings, I think that makes a lot of sense, but not all of these configuration options can be stored in a local config file. In particular, modifying the set of allowed labels seems like it needs to be more closely integrated with git bug.

  3. MichaelMure
    added
    enhancement
    on Oct 7, 2018

  4. MichaelMure commented on Oct 7, 2018

    @MichaelMure
    MichaelMure
    on Oct 7, 2018
    ContributorAuthor

    As @adamslc stated, there is a need for two different kind of configuration:

    • personal configuration (user info, keybindings ..): git config is perfect for that, config can be defined for a specific repo or globally
    • project configuration (labels, comment template ...): this kind of configuration should be
      1. defined by project administrator and if possible restricted in edition to only them
      2. scope should be global to the project, regardless of code branches or if the local repo is up to date: obviously this impossible to achieve entirely, compromise will be needed
      3. conflict free

    Author data specific to git bug. I'm not sure if this exists?

    Currently git-bug source the Name and Email from the git configuration. It already support AvatarUrl (no source apart from the github importer) and will soon support Login (github importer as well). In the future, it will most likely support other things like a keypair to sign bug editions.

  5. MichaelMure commented on Oct 7, 2018

    @MichaelMure
    MichaelMure
    on Oct 7, 2018
    ContributorAuthor

    I'd like to have the following UX guidelines:

    • git-bug should work out of the box without any kind of config required. A good example would be the set of labels: out of the box, any label is valid. Once a config is defined, only those are accepted as valid.
    • if there is a need to do an opinionated default choice, it should favor a small project/team. Bigger team will have the time to tweak git-bug as needed.
    • user should not have to know how and where the configuration is stored to manage it. Power user can still edit the config directly if they want (kind of like the .git/config file)

  6. MichaelMure commented on Oct 7, 2018

    @MichaelMure
    MichaelMure
    on Oct 7, 2018
    ContributorAuthor

    I see different way to store the project scoped config:

    • (1) simple config file (.git-bug) stored with the code

      • Pros
        • obvious for the user
        • simple
      • Cons
        • branch scoped, this can lead to some operation considered invalid because the current branch has a different config
        • pollute the code

    • (2) a simple hidden ref holding a series of commit, each commit holding the full config

      • Pro
        • actually global scoped
        • simple
        • store the full history of the config
      • Cons
        • hidden
        • can have conflict with concurrent edition, conflict that will need to have a way to be resolved

    • (3) a hidden ref holding a series of commit, each commit holding an edit operator, a for the bug data

      • Pro
        • actually global scoped
        • conflict are resolved automatically
        • store the full history of the config
      • Cons
        • hidden
        • complex

    One thing to note is that the configuration will change very rarely, and probably by a unique person at a time. I'm leaning toward solution (2) but this needs more thinking.

  7. adamslc commented on Oct 7, 2018

    @adamslc
    adamslc
    on Oct 7, 2018
    Contributor

    +1 for options two or three. Having a tracked file that defines git-bug settings seems really broken given git-bug's data model.

  8. github-actions commented on Jul 23, 2024

    @github-actions
    github-actionsbot
    on Jul 23, 2024 – with GitHub Actions

    This bot triages untriaged issues and PRs according to the following rules:

    • After 90 days of inactivity, the lifecycle/stale label is applied
    • After 30 days of inactivity since lifecycle/stale was applied, the issue is closed

    To remove the stale status, you can:

    • Remove the lifecycle/stale label
    • Comment on this issue
  9. github-actions
    added
    lifecycle/stale
    on Jul 23, 2024
  10. sudoforge
    added
    area/configurationRelates to git-bug configuration
    kind/featureRelates to a new feature
    priority/important-longtermImportant over the long term, but may not be staffed and/or may require multiple releases
    and removed
    enhancement
    lifecycle/stale
    on Aug 3, 2024

  11. github-actions commented on Nov 4, 2024

    @github-actions
    github-actionsbot
    on Nov 4, 2024 – with GitHub Actions

    This bot triages issues in order to help the maintainers identify what
    needs attention, according to the following lifecycle rules:

    • After 90 days of inactivity, lifecycle/stale is applied
    • After 90 days of inactivity since lifecycle/stale was applied,
      lifecycle/rotten is applied

    This bot will not automatically close stale issues.

    To remove the stale status, you can:

    • Remove the stale label from this issue
    • Comment on this issue
    • Close this issue
    • Offer to help out with triaging

    To avoid automatic lifecycle management of this issue, add
    lifecycle/frozen.

  12. github-actions
    added
    lifecycle/stale
    on Nov 4, 2024
  13. github-actions
    removed
    lifecycle/idle
    on May 3, 2025

  14. khimaros commented on Sep 26, 2026

    @khimaros
    khimaros
    on Sep 26, 2026

    as discussed here: https://news.ycombinator.com/item?id=49847835

    i'm looking forward to ability to define custom statuses

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/configurationRelates to git-bug configurationkind/featureRelates to a new featurepriority/important-longtermImportant over the long term, but may not be staffed and/or may require multiple releases

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions