When a user have more than one repository would be interesting to know in which repository He is connected to. This can avoid actions in the wrong repo.

Cláudio Silva (claudioantonio) added label area/ui/web 4 years ago

I suppose this should be hidden if we only have the (unnamed) default repository.

I have a question. Can one git-bug instance already manage multiple repositories? I thought that I have to run multiple instances per repository. If this is currently not possible, maybe doing the same as gopass - multi stores, might be an option (for future reference).

The core and the GraphQL API support it, but there is no tooling (CLI, config file ...) around to actually register multiple repo.

See https://github.com/MichaelMure/git-bug/blob/master/cache/multi_repo_cache.go#L23 : nothing is calling this function.

https://github.com/MichaelMure/git-bug/blob/master/api/graphql/schema/root.graphql#L2-L3 : you can query another repo if you have one.

Michael Muré (MichaelMure) changed the title from WebUI - show the name for the browsed repository to WebUI - show the name for the browsed repository 3 years ago

Michael Muré (MichaelMure) added label Easy pick 3 years ago

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 Easy pick 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/rotten 10 months ago

github-actions (github-actions) removed label lifecycle/stale 10 months ago

sudoforge removed label lifecycle/dormant 7 months ago

@sudoforge, digging into this a bit I have a suggestion:

1. if there's a repo name that's not the default __default, we display it in the app bar
2. in the repo cache, [where we set the name by default][1], we update it to pull a git-bug.repo-name config if it's present, as a way to short-circuit not having a way to name it
   • I think we can do it at cache creation, because the repo includes methods for config pulls, but obviously I'm not super familiar with the codebase
3. future ticket can allow rename from within UI, and change the name to a dropdown component if we want to handle multiples [1]: https://github.com/git-bug/git-bug/blob/9942337bf52d0b183055690ef0651babe74c51ae/cache/repo_cache.go#L79

screenshot manually hacked together with devtools, but it's the general idea

(also shows where the tabbed-nav would move, getting rid of the "coming soon" links)

if there's a repo name that's not the default __default, we display it in the app bar

the current value of the "repo name" will always be __default, though, due to the current implementation of the cache.

in the repo cache, [where we set the name by default][1], we update it to pull a git-bug.repo-name config if it's present, as a way to short-circuit not having a way to name it

i think i'd rather refactor the way we determine the repository name. repositories have a few different names:

• the name of the folder that the git repository lives in on disk
• the name of the repository as derived from one or more remote URIs
  • in the simple case, where a user just has a single remote, usually named origin, this is likely a better source for deriving the repository name, but it gets tricky when you consider that (1) remote names are arbitrary and (2) you can have any number of remotes in a git repository

so, taking that into consideration, i think defaulting the name of the repository to the basename of the directory the repository lives in makes a lot more sense than __default.

that said, in the current implementation of the multi repo cache, that could result in potential conflicts (e.g. two repositories on disk: /code/a/foo and /code/b/foo), so this "name" (at least internally, as it is represented in the cache) really needs to be a unique identifier. something like the checksum of the full path might work.

i'm undecided on whether or not the repository name should be a user-configurable attribute. i think i'm leaning towards "no", especially if we are deriving the name in this manner.

future ticket can allow rename from within UI, and change the name to a dropdown component if we want to handle multiples

given the above, i'm leaning towards disagreeing with sourcing the name of the repo from the git configuration, and thus, renaming isn't a thing that should be supported. maybe "moving" it can be, though (which would actually move it on disk)?

(so, the feature could be implemented today by just showing the value you're getting back from the API, but not rendering anything if the value is __default)

okay, after thinking about this for a few more seconds, maybe the name should be independent from the thing that's stored in the cache, e.g. git-bug.cache-id and git-bug.repo-name

the feature could be implemented today by just showing the value you're getting back from the API, but not rendering anything if the value is __default

This is the way. How the repo is named is not a concern of the webUI, it should just use whatever the graphQL API says.

Those names will come from logic in the webui command, which can be implemented however we want.

Yep, that's great; the webui change does exactly this, hiding if the name isn't __default - I will avoid any backend changes to default or pull anything new. I do think that defaulting to the directories base name when first run would be a good idea, if only because it'd let there be something in the header other than the logo

This is what I've currently got, and I'm curious what you'd like me to move with (the ones with a name showing are for testing styling, __default would never show):

i think i'm of the opinion that if there's a repo name, it should replace git-bug in the header. as-is, it's a little visually confusing, as it bleeds into the navigation links.

somewhat related, i also think that we shouldn't have any navigation link at all, since "bugs" is the only view.

Easy enough, I think that all makes sense; I'll have two related PRs up shortly; the react 19 + router upgrade, and this (since I forgot to cut this before the upgrade lol)

you could just cherry-pick it:

git fetch
git checkout origin/HEAD
git cherry-pick <commit>
git push origin HEAD:refs/heads/my-branch-name

er, well, whatever you've named the remote.