@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.

@j-f1 said:

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

@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.

Michael Muré (MichaelMure) added label enhancement 7 years ago

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.

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)

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.

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

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

github-actions (github-actions) added label lifecycle/stale 1 year ago

sudoforge removed label enhancement 1 year ago

sudoforge removed label lifecycle/stale 1 year ago

sudoforge added label area/configuration 1 year ago

sudoforge added label kind/feature 1 year ago

sudoforge added label priority/important-longterm 1 year ago

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.

github-actions (github-actions) added label lifecycle/stale 1 year ago

github-actions (github-actions) removed label lifecycle/idle 7 months ago