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?
Hi! Welcome here.
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
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.
I don’t buy into the narrative
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.