Coming from Git and Subversion this feature was difficult for me to understand. In those systems the analogy makes sense because you can draw the repository history as a bunch of timelines that are related to a main timeline (except when you create an orphan branch and then the analogy doesn’t make sense anymore).
After I read that in Pijul branches are just sets of patches I got quite confused and I didn’t understand what was its purpose. I had to read about spontaneous (non-)branches in Darcs before everything clicked.
So I wonder why not rename the feature? I think set is a good name because that’s what they are but if we want an analogy why not pool or workspace? This would make the fork and prune (I read that’s how delete-branch will be renamed) subcommands a little longer (because we would need something like new-pool or new-set or whatever) but I think the mental model is more important.
And of course this is matter of opinion. Maybe someone will get the concept faster than me but in any case I think it is better to be precise (and that’s the reason that patches are called patches and not commits)
This is a very good point, I was explaining this to a friend this week, and advised him against using branches in the beginning, and he said “I think I understand, patches commute, but I like my stuff clean”.
I had to draw a set and a timeline on my whiteboard to make the distinction clear.
Changesets are great, especially since I don’t like the term “patch” very much.
Because (1) patches sounds like a quick fix and (2) like they apply to a specific context.
Both are false in Pijul. Other properties of patches are that they describe changes to a file, and are generated by a diff, which are both true in Pijul.
Yes please! IMHO it doesn’t matter that much if they are called patches or changes but once a concept is chosen I think it must be used everywhere to avoid confusion
In my yet-to-be-released qt interface for pijul, I use change for the elementary changes within patches, and contribution for (current) patches. I’ve kept branch, but maybe variant would work?
I don’t know about contribution. The more I think about it, the more I am convinced we should not throw away the word patch, as it is something familiar for vcs user and darcs users more specifically.
Maybe just renaming branches as patchsets would be enough to clear people’s mind?
The more I think about it the more I think patchset or just set is a better name for what currently are called branch. This comes from my discussions on Twitter about why I’m exited about Pijul. At some point I used the term bag, a “bag of patches”, and it was confusing.
set coveys the idea that there’s only one copy of each patch in the set and I’m more and more convinced that analogies are not good
Hi, I’m late to this conversation, but having used Mercurial Queues (mq) and quilt in the past (and having loved the flexibility and power those came with), I’m quite excited for pijul. As you might guess, I’m very much in favor of keeping the term “patch.” I agree that branch is not a great name. I would prefer the terms from mq and/or quilt: stack or series.
Hi! You’re not actually late, because this is still undecided. I hope to release the super-fast version of Pijul in 2019, but that’s not guaranteed. Stack or series have the disadvantage that they sound sequential, which Pijul tries to avoid as much as possible (Pijul patches that could be produced in parallel always commute).
I have been reading about how pijul patches can commute, and I wondered if stack or series would not fit well because of that. If that’s the case than patchset is probably the best name.
I see the suggestion for changeset, but since other version control systems use that name to refer to a single revision/commit/patch, that would probably be confusing.
I’m new to this whole project, and branch also confused me.
Having changsets in SVN and how it build a file by sequentially applying changesets (which is what makes it slow), that’s not a word that should be used either, but it makes me wonder if Pijul is doing the same thing as SVN in that regard.
But reading the manual, I got confused between fork and clone, which are both used by other VCS. I’m still not sure what the difference is between the three commands.
combined patchset or merged branch (combined or merged because of a shared change) → changennset
In terms of typical nomenclature, a patch (singular) consists of a number of changes to a number of files, and it may be useful to have a term that refers to these (typically semantically grouped) changes (plural), but that doesn’t deviate substantially from the term change, and can be suffixed with -set.
The term changes (plural) is ambiguous when suffixed with -set, and web searches for changes would tend to lose the distinction from change (whereas the distinction between patch and hunk/fragment is typically not ignored in search results). Instead, (using the old English masculine nominative/accusative -en pluralization) I propose the word changen (in lieu of patch or commit) to refer to a group of changes that you might semantically want to apply at the same time to maintain code consistency, and the word changenset (in lieu of changesset/patchset or branch) to refer to a set of (only partially ordered [for dependencies], unique) changens that, if semantic considerations were ignored, could be flattened (i.e., unioned) into a (semantically ambiguous) set of changes (i.e., changeset).
To (perhaps unnecessarily) extend the terminology for generically referring to a semantic hierarchy (even though, in the implementation, arbitrary metadata addresses the hierarchical distinctions and edge::EdgeFlags addresses the conflict distinctions), the term changenn could be used to refer to the additional layer of semantic grouping when a changen (e.g. a patch for changing an identifier consistently/atomically across the codebase) is (semantically) closely related to (and, for code consistency [slightly more generally], is to be applied at the same time as) another changen (e.g. a patch for changing a user interface apropos that identifier change), and then the term changennset could be used when a changenset (~patchset~branch) possibly could otherwise be considered as a combination of multiple separate changensets (~patchsets~branches) except for a shared changen (~patch~commit) that ties the changennset together like a bundle (e.g. when two feature branches share a few changes because the features themselves are related).
Obviously, for people coming from a different versioning system, having to map a term with a mental image (e.g. patch, branch) to a suffixed generic term (e.g. changen, changenset) would be a difficult transition, though having consistent terminology that maps well to a clear understanding of exactly how the commutativity and associativity turtles go all the way down to the intra-line edit may be worthwhile in the long run.
Really I’d say a branch is - the result of checking out a changeset and all dependencies, and nothing except that changeset and its dependencies. Obviously there are some changesets where that is a more useful operation than others, e.g. you probably don’t want to distribute or advertise or attempt to compile a branch with conflicts in it; despite changesets with ordering conflicts being otherwise extremely valid, and much of the purpose of the Pijul patch algebra over something like git.
(Similarly, something like the Nest needs to be able to display concrete branch checkouts and not just changesets, despite them not fundamentally existing in the data model.)
I’m a bit irritated by the use of the word “set”. Isn’t it so that the order of patches in a “set” matters, that is, that a “set” is actually a list, perhaps one without duplication of elements?
In Pijul, the order doesn’t matter, as long as dependencies between patches are respected: obviously, you can’t edit a file before adding it. However, two patches produced in parallel have no reason to be ordered. In Git, they are, but not in Pijul.
The word “set” is actually accurate, since the state of a repository is actually a set (ordered by the partial order given by dependencies). Obviously, in order to make it more intuitive for users, Pijul also has an ordered log of operations, but that is an extra feature and is not needed by the theory: earlier versions didn’t even have that log, and patches were routinely reshuffled when pushed or pulled, without any incidence on the end result.
In Git, a branch implies a parent. In Bazaar, the branch is main focus (logs are shown relative to the branch). In SVN, branches are more like historical markers.
What is the purpose of a branch in Pijul? Maybe that will suggest a better word.
I don’t think that making up words like changen helps understanding.
I’m also skeptical about using the old English plural as in “changen”. I think it hinders understanding, as most people won’t intuitively grasp the intended meaning and need an explicit explanation. For example, when I first saw “changen”, my brain’s subconscious language processor thought it must have to do something with generators, because it ended with “gen”.
