do you mind if I try to create a pijul service for sourcehut? or do you have plans for nest
1 Like
I do have plans for the Nest, but feel free to create a Pijul service for sourcehut.
Edit: careful about the license, libpijul is GLP-2.0
May I ask what features of sourcehut you would like to see in the Nest ?
I’m not very experienced with sourcehut, but I like how you can search on every section.
GitHub has indicators for what language is used, which is very helpful. Sourcehut has tags, but I don’t see other descriptors like language.
Sourcehut makes it clear how to get the files (at least when you are logged in).
The Nest needs easy links to download a zip or a single file.
the complete lack of javascript, all processing is server side
the browser only receives html and css
This already exists, but isn’t public yet, because tags aren’t finalised, and are necessary to implement a meaningful version of that. This thread is useful for me, as it tells me what to do with the Nest-side variant of tags I have in preparation.
Not only do you not seem very informed about SourceHut (even the front page has javascript!), you also don’t seem to know much about the Nest. Avoiding Javascript is also a goal of the Nest. There is very little JS in it, and each bit of it I’ve added was done as an answer to sensible user requests.
That is good news! In conjunction with being able to download easily, it would be great if the size was visible. I’ve been so long on a limited bandwidth connection, it really helps to know how big things are.
For instance, if you were to jump into contributing to the Gutenberg editor for WordPress, when you clone the repo, you would be very surprised to have to wait until 2 Gig download.
Speaking of clones, does the Nest have an interface for forking a repository? (I don’t know if sourcehut does)
It used to have one, an the internal format still allows it, but it isn’t exposed to the user anymore, for three reasons:
- Forks are used as a way to make PRs/MRs in Git (so SourceHut probably has it). Pijul doesn’t need that, we have patches, that’s a way better interface. Actually patches are so much better than commits that even GitHub, GitLab and SourceHut show commits as patches!
- If we have a better way, we shouldn’t keep the old one, since that is confusing for users: newcomers to the Nest will want to use their old habits from GitHub, and might never see the benefits of patches.
- Forks are also sometimes used as a hostile move, and we certainly don’t want to encourage hostile practices, there’s enough hostility in the world (including from SourceHut’s author himself, who is quite “outstanding” in that regard).
1 Like
None of these makes sense to me. The main point of open source is that it can be reused and contributed back to.
I guess you have to decide what the Nest is really for. Is it just an off-site backup for developers? Or is it a place to collaborate and find interesting projects to join or reuse? Is it an online interface to the full Pijul command set?
How do you propose that people make Pijul patches without a copy of the repo? (I would argue that commits are patches, with a different name.)
The better way isn’t visible on the Nest either. There is no interface to edit a file (or add/delete/rename a file) as a patch to a repo.
I think that is the rarest case. I think everything can be used in a hostile way. You can use an airplane as a way to destroy a building, but that doesn’t mean you get rid of all airplanes.
It is meant to be a social place. Many people have already successfully contributed (including to Pijul itself!) using patches, without any need to fork or use an online editor.
This could be because you haven’t really understood them. Just one example:
If you believe patches are commits, you will not get any benefit from using Pijul: Git will be faster and more useful for you in 100% of cases.
Also, I hope you understand that I took the time to answer using arguments. If some are unclear to you, I ask you to consider that they may still be right: I designed and wrote most of this version control system and most of its theory, so I know what I’m talking about.
Yes, they had to use the command line to get the copy of the repo and to send it back. As the Nest is online, a way to make a patch online would enhance it.
I’ll be the first to admit that I don’t understand. But it’s not for lack of trying. I guess it’s an indication of the explanations either aren’t adequate or are from a very different way of thinking.
Maybe you are speaking from an internal representation aspect. Or maybe the way they are referenced. Or maybe the difference has never been made clear anywhere. As far as I can tell, a commit is a way to talk about a set of changes to a group of files. That’s what I thought a patch was also. Please improve the documentation if that is the wrong idea.
(I don’t use Git unless I have to. I prefer Bazaar/Breezy.)
Yes, I appreciate your time and answers. I know you wrote Pijul. I hope you can gain some insight from us outsiders looking in, and see where the gaps are. My Rust knowledge is rudimentary, so I have only the meager docs and discussions to go by, but then people shouldn’t have to read the code to “get it”.
Have you read the following page: Why Pijul - The Pijul manual where the word commutation is repeated many, many times?
Yes, and I understand that concept. I know you can’t unsee all the implementation details, but that is not what most of us are talking about.
When you say commit and patch, it could be any version control system. They all have the same goal, and have different internal structures, and different caveats in their methods. Really, it’s just a label for the difference between two versions, however it is represented and used.
Alright, I see where you’re coming from. This isn’t true: commits are not diffs, each commit represents a full version of the entire repository, whereas diffs represent changes. The main difference is not an implementation detail, it is the fact that diffs do not necessarily happen between two versions. Even though for any two versions, you can compute the diff between them, some diffs might not represent the difference between two versions.
For example, a diff relative to one file A might still be valid if other changes happen in unrelated files in the same repository. This is why you can commute changes on file A with changes on these other files. That particular diff isn’t a diff between two versions, because it is the same diff regardless of the exact versions of the other files in the repository.
Note that in Git’s internal representation, some commits are represented as diffs, but that is an implementation detail.
Strictly speaking, commit is the verb, the command, which dictates a new version to control. Can I assume that is equivalent to record in Pijul?
In GitHub and sourcehut, a commit is represented as a list of files with changes highlighted. GitHub will tell you how many commits this branch is ahead or behind master(or parent).
Is there something in Pijul that is equivalent to a commit?
If Pijul’s change is just a delta, maybe call it that. Wouldn’t that make it like SVN?
I really don’t like defining terms relative to other VCSs, since everyone’s knowledge of them is different.
The Nest doesn’t show the dependencies between changes in the main list. When it does show them in an individual change, it’s just a big hash. It would be better to abbreviate the hash and show the message associated with it. (also, the diff doesn’t show any context or is that an option somewhere?)
As written in my previous answers, and on the Zulip, no. A commit is a full version, “committing” means “registering a full version”, whereas a change is a set of changes to the repository. My previous answer has a very clear example (which you don’t comment on, I don’t know if your read it) where the two are different.
No, and I’ve already stated that in my previous answer: commits in Git and SVN are the same, they’re a full version. Changes in Pijul are NOT commits, they are changes, not full versions. The exact representation of commits (diffs in SVN, and mixed diff/blob in Git), is an implementation detail, COMMITS ARE FULL VERSIONS OF A REPOSITORY.
I read it, but perhaps it wasn’t clear, because you are using the same words “change” and “diff” for multiple things.
Is there such a thing as “a full version of the repository” (equivalent to commit) in Pijul then?
And the corollary, is there such a thing in SVN or Git as “a set of changes to the repository”, or is that a tag?
If you quote a precise bit of the example that you don’t understand, I can clarify it, but just dismissing it as “globally unclear” isn’t… clear.
It’s planned to be a tag, but this isn’t public yet. There are already state identifiers, based on elliptic curve tricks to allow sets of changes to have the same version identifier regardless of the order.
Semantically, a full version is a set of changes, but for performance reasons, we don’t represent it like that.
No, and this is why Darcs and Pijul exist.
Sorry for necrobumping, but I thought it is maybe useful to add a bit about the core idea of sourcehut, and compare it to pijul/nest, as far as I understood:
tl;dr: Sourcehut is diff-based (not snapshot-based) and git is federated via email. The nest/pijul is patch-based and pijul is federated via harmless push. Naturally, the nest is centralized since it hosts central places for collaboration. But in the long run I’d find it beneficial to have alternative open-source possibilities to publicly (self-)host a pijul collaboration hub.
Git is already federated and decentralized, since it is originally built around an email diff workflow, as the author argues. Sourcehut tries to make the email-centered, federated git workflow easier, by developing an interface more accessible for Git{Hub,Lab,…} pull-request trained minds. So in principle, it is centred around pushing diffs, which are kind of poor-man’s patches: Whereas you can push a patch directly to a nest repo, in sourcehut you push the diff to a mailbox/mailing list and it gets (maybe) applied, as a new commit. Here, pijul is superior, because you can send patches somewhere else, and they keep their identity. You can even push to a repo without causing harm. In sourcehut, you are experiencing the typical git mismatch between patches as UI and snapshots as internal representation, which is easily confused when working with git.
What the nest is missing, compared to sourcehut, is the web based sending of patches (for which sourcehut also has a button for cloning a repo on the server) and some stuff like CI, wikis, todos, mailing lists,… some of which are up to taste, surely.
There was once a thread about a distributed nest. Since you can freely push anywhere and the online repo is only the central place to collaborate on one project, I don’t really see the point any more.
What is too centralized for my taste, currently, is that the nest is closed source and it is the only web gui for publicly hosting pijul repos (or is it?). If you plan to open source it eventually (no hurry), then everything will be fine. Otherwise, someone should write an alternative at some point, e.g. a sourcehut integration, if pijul patches can be exchanged via email just as well, instead of pushing (i had it on my mind, but time…).
2 Likes