Avoiding a necrobump of the last roadmap question in '19.
We have Nest. We have ssh:. We don’t have darcs send --email. Is that where tag is going? To share via patches, I think what pijul needs (is missing) is an analog to darcs’ changesets – patch collections. A user could cobble something together with pijul change, generate a bunch of changes, bundle them into a tarball, email that; and on the other end, untar and – one by one – pijul apply. Alternatively, changes could be collapsed with diff --tag, although the result would ideally be tweaked to fill in the authors and message fields.
ssh servers are impractical for most people, which forces pijul users to Nest for collaboration. I think tying pijul to a web service limits the usefulness of the tool.
It seems as if tag is a step in the direction of creating patch sets. There’s a comment in a ticket that tags is currently broken and due for a redesign; I’m curious about what the objective of tags is. If it isn’t ultimately for collaboration via sharing changesets, is there any plan to eventually have some analog of darcs send, to allow sharing change sets via email?
So, you could definitely email a bunch of changes, but it is true that the command for that doesn’t exist yet. Nothing prevents you from adding one though, even as an external tool (similar to Git, if you name your binary pijul-email, it becomes accessible using pijul email).
Tags are a bit different. They were planned to be similar to commits in Git, but they somewhat missed that goal so far, for two reasons:
They are costly to verify, and hence don’t save much time when transmitted, they’re more like points in history that you may want to come back to again in the future. There are a number of issues when verifying a tag hash efficiently, which is why we always require them to be signed.
A project I have if Pijul gets more adoption and bigger projects start using it, is to add a feature to repositories using tags, which would turn Pijul into a hybrid patch/snapshot system. However, this planned feature is totally backwards-compatible, but even though it would require just a few days of work, I don’t want to implement it without knowing that someone actually needs it (meaning that they can’t use Pijul withouth that feature, i.e. they have giant repos, which in turn implies that they could pay for developing that extra feature).
This doesn’t mean that tags or commit-like features are necessary or useful, in fact Pijul is simpler and easier to use without them.
Nothing prevents you from adding one though, even as an external tool
True; I’ve tested various ways of accomplishing this, and it wouldn’t be more than a few lines of bash. The hiccup is during the apply, when there could be conflicts, but if I constrain the tool to working only in channels (at least, on the apply side), then the conflict can could be kicked a bit.
which would turn Pijul into a hybrid patch/snapshot system.
Could you expand on this some? Tags would be the snapshot, but how would the patches show up?
I’m mostly interested in the sharing part of this, and specifically in how to work without Nest. Am I wrong that Nest and ssh are the only pragmatic ways to distribute change sets? Pijul has no native equivalent of a Mercurial bundle, or a darcs dpatch, right? Something that could be, e.g., attached to a chat?
I’m with you about feature creep; I do think some standardized, official “Pijul-approved” format would be useful.
if Pijul gets more adoption and bigger projects
I think there’s a chicken/egg thing here. There’s a negative incentive to commit to Pijul if the only easy way to collaborate with others is over ssh and Nest. It would seem to be an important topic for a tool designed to facilitate collaboration.
I was specifically talking about scaling issues. At the moment, I don’t think they are the main problem blocking adoption. If you want to work with Pijul, including on rather large projects, you already can. I don’t buy into the narrative of “it needs to scale to banking codebase scales with 40 years of history in order to be useful for my startup/open source project”.
The main concept would still be patches, because snapshots are not a very useful concept for working (there is a reason why most Git UI show snapshots as diffs with other snapshots). The only reason to use snapshots is when you want to efficiently go back to a specific point in time, like a release number for example. This idea would allow to be a little more efficient in disk usage.
FWIW, I agree. For me, it’s more about collaboration. I’m not likely to move off of SourceHut; the CI, wiki, issues, projects, lightweight webpages, mailing lists - the ecosystem - provides what I need, and I’m happy there. So then it becomes a question of “how do I collaborate with contributors?” Right now, it’s challenging; Sourcehut doesn’t support Pijul directly, but that’s not usually a blocker because of the excellent patch management support – people can and do work together on projects entirely through mailing lists.
I used darcs for a few years, and really liked it’s changeset approach. I’m trying to script together something similar for pijot, but FYI that’s the direction I’m working towards.
Snapshots were amazing when they were novel, and a huge improvement over systems like CVS and ClearCase, but obviously I think a theory of patches is a better approach – or else I wouldn’t be exploring Pijul.
Lately I’ve been thinking about a starting project like reporat for pijul, and a tool or command like what @ser is talking about would be great for that.
Pijul seems like a vcs where you could make a UI with features for viewing a repository (including downloading changes locally) with all of it implemented as static HTML and text files.
Building it as a plugin for a popular static site generator could be good for pijul’s visibility, too.
Doesn’t the Nest do most of that? (It is being open-sourced…)
I think there is a command missing in Pijul, which is to show the contents of a file at a specified state.
I wrote a shell script to output HTML to show the dependency graph.
It does, but I think there is a use case for having a way of sharing code changes without needing logic running on a server to do it. Ser’s original post about being able to email patches, or being able to show changes on a static HTML site, would be great for projects with a smaller number of collaborators who don’t need (or want) to use a full software forge. Plus, it’s just really cool.
think there is a command missing in Pijul, which is to show the contents of a file at a specified state.
That would be very useful. Seems like something any GUI or repo browser would make heavy use of.
I wrote a shell script to output HTML to show the dependency graph.
Nice! That’s awesome. That would be a great addition to any static-site pijul repo UI.
Oh, I see what you mean. Yes, that will definitely be helpful. I’m most interested in seeing what kinds of things the nest returns when you try to clone a repository over https, and if those things could possibly be served as static files.
