Forge Database location

[Ergus]

Hi:

I am experimenting with Forge these days because it is a very interesting project with the potential to move all my development workflow to emacs. So thanks for it!!!

I have experienced a couple of issues (or un-intuitive behaviors) with the interface but I will report that independently once I find consistent reproduction.

However at the moment what I want to ask is about a design decision of using a centralized database.

One of the key parts of git is the total isolation between local clones. So my question is why forge does not follow the same approach and creates an independent database for every clone in the local directory. Lets say .forge or .git/forge-something

I think that in the same "git spirit" we could have a forge-clone == forge-add-repository, which creates the local database? and potentially we could (for example) forge-clone from two local repositories directly. Does it makes sence?

Best

[tarsius]

Maybe one day I will implement a "git-native" issue tracking solution and that would contain each repository's issue database within itself.

One of the key parts of git is the total isolation between local clones.

Forge, however, is an interface to centralized Git hosting solutions. The centralization has its downsides, such as the control it gives to companies like Microsoft, but it also has technical benefits. We shouldn't give up on the benefits of the centralization just because we are of the downsides, that would only hurt us without sending a message to those in power.

One such benefit is that clients can get a list of new/updated issues across all tracked repositories from a single source. Or just a few sources, when using multiple Git forges. In any case, it is simpler, faster and more reliable to fetch from one/few forge(s) than to poll a hundred individual repositories.

Having few sources that can be fetched in one go, is a more desirable property for "issues" than it is for Git data. I usually only update the Git clones that I actually want to work on. When it comes to issues, pull-requests and discussions, I do not have the freedom to decide what get my attention.

Here it is often other people who dictate what I have to turn my focus too. I.e., like with an email client, I fetch everything at once, and store it in a single place, and then I look at the list of new communications and decide what I need to deal with now and what can be shelved for later. Like with email, it makes sense to store this data in a single "database" instead of artificially spreading it across different places. This makes it easier to implement features such as "list all unread email" or "list all new pull-requests".

IMO what matters is that the data is stored locally. In a sense whether multiple databases are used or a single local database, is an implementation detail. Which is easier to implement and which feels more "natural" depends on factor such as the data source and preconceived ideas about what would be the "correct" way to do it.

I think that in the same "git spirit" we could have a forge-clone == forge-add-repository, which creates the local database? and potentially we could (for example) forge-clone from two local repositories directly. Does it makes sense?

I think that conceptual purity aside, this would only have drawbacks. Sure using forge-clone instead of magit-clone/git clone would be cool and would make sense. But afterwards it would become a nuisance that you always have to "forge pull" in both clones. You would frequently want to deal with an issue that you know you have already fetched, only to find that you only fetched it in the other clone of that repository.