It would be nice (for self hosting purpose) to be able to create so-called “bare” repositories (at least that is how git calls them), where the content of the repository is not output.
Yes, but why? Git needs bare repositories because it doesn't handle patch commutation, and so cannot handle edits to the working copy in parallel with a push. That seems like an antifeature to me.
Well, I think I recall you saying once the Nest was not outputing its repositories because, well, there is no need for that server-side. That is basically the same thing here.
So, just to try being clearer, I personally would love to have this feature for several reasons:
There is this idea of “constraing repo usage where it makes sense” and “don’t waste resources.”
Of course, if you don’t want this feature in pijul, that is fine too :). I would probably write a patch and makes it lives in my pijul worktree.
Wait, don't get me wrong, asking why doesn't mean I don't want it.
The reason I asked is entirely related to the risk of confusion with Git. Can you explain how you would implement this?
I didn’t understand it differently (sorry if the tone of my answer let you think otherwise).
To answer your question, a first and easy(-ish?) version would be to add a boolean field in a repository configuration, and to modify the behavior of several commands accordingly:
would systematically fail, and probably
What do you think?
Ok, I think I know what we need here, and how to implement it.
We need another type of repository, called BareRepository. Any repository could be opened with that type, because it would contain only a subset of the tables:
Then some commands, such as log and patch, would stop requiring a full Repository. That's a first step.
The next step is to allow apply to detect whether it's working in a full repository or a bare one, and to take action accordingly: if it's a bare one (i.e. if the relevant tables are 0 in the pristine, which is quite easy to detect in libpijul::backend). If the repository is bare, just add the patch hashes to the relevant branch, but don't apply anything.
This would allow Pijul to scale to almost arbitrarily large central repositories (and even better than Git). The remaining problem for scaling, which I'm taking care of, is to have large local repositories.
I'm tagging this as a good first bug. It doesn't mean that it's trivial (to begin with, it's in libpijul), but it's a good way to learn how Pijul represents things internally, and the risk of making mistakes is almost zero.