do you mind if I try to create a pijul service for sourcehut? or do you have plans for nest
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 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.
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).
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: https://pijul.org/manual/why_pijul.html 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.
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?
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.