# Calling branches "branches" is misleading
**URL:** https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276
**Category:** Development
**Created:** [February 4, 2019, 2:32am UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276 "2019-02-04T02:32:56Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@tae](https://discourse.pijul.org/u/tae)
#### Post date: [February 4, 2019, 2:32am UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/1 "2019-02-04T02:32:57Z")
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](https://discourse.pijul.org/t/spontaneous-non-branching-vs-tree-style-branches/47/) 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](https://nest.pijul.com/pijul_org/pijul/discussions/60)) 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)
Edit: I think _state_ could work too
---
### Author:  [@pmeunier](https://discourse.pijul.org/u/pmeunier)
#### Post date: [February 23, 2019, 11:30pm UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/2 "2019-02-23T23:30:07Z")
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.
---
### Author:  [@tae](https://discourse.pijul.org/u/tae)
#### Post date: [February 25, 2019, 2:56pm UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/3 "2019-02-25T14:56:32Z")
I like changeset too but I think anything is better than branch 😅
---
### Author:  [@hyperfekt](https://discourse.pijul.org/u/hyperfekt)
#### Post date: [March 3, 2019, 3:38pm UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/4 "2019-03-03T15:38:48Z")
> [@pmeunier](#):
>
> I don’t like the term “patch” very much.
That’s interesting, why is that? To me, ‘change’ sounds much more ambiguous than ‘patch’.
---
### Author:  [@pmeunier](https://discourse.pijul.org/u/pmeunier)
#### Post date: [March 3, 2019, 4:10pm UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/5 "2019-03-03T16:10:38Z")
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.
---
### Author:  [@lthms](https://discourse.pijul.org/u/lthms)
#### Post date: [March 3, 2019, 4:32pm UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/6 "2019-03-03T16:32:05Z")
Maybe it would make sense to start talking about “changes” in places of “patches” and “changeset” in place of “branch,” then?
---
### Author:  [@tae](https://discourse.pijul.org/u/tae)
#### Post date: [March 3, 2019, 4:46pm UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/7 "2019-03-03T16:46:08Z")
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
---
### Author:  [@flobec](https://discourse.pijul.org/u/flobec)
#### Post date: [March 4, 2019, 7:32am UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/8 "2019-03-04T07:32:02Z")
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?
---
### Author:  [@lthms](https://discourse.pijul.org/u/lthms)
#### Post date: [March 4, 2019, 5:13pm UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/9 "2019-03-04T17:13:43Z")
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?
---
### Author:  [@tae](https://discourse.pijul.org/u/tae)
#### Post date: [August 31, 2019, 1:45pm UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/10 "2019-08-31T13:45:19Z")
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
---
### Author:  [@krupan](https://discourse.pijul.org/u/krupan)
#### Post date: [October 29, 2019, 7:54pm UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/11 "2019-10-29T19:54:48Z")
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.
---
### Author:  [@pmeunier](https://discourse.pijul.org/u/pmeunier)
#### Post date: [October 29, 2019, 8:30pm UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/12 "2019-10-29T20:30:33Z")
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).
---
### Author:  [@krupan](https://discourse.pijul.org/u/krupan)
#### Post date: [October 29, 2019, 8:48pm UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/13 "2019-10-29T20:48:03Z")
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.
---
### Author:  [@joyously](https://discourse.pijul.org/u/joyously)
#### Post date: [July 12, 2020, 8:54pm UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/15 "2020-07-12T20:54:58Z")
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.
---
### Author:  [@brandon](https://discourse.pijul.org/u/brandon)
#### Post date: [October 2, 2020, 2:32am UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/16 "2020-10-02T02:32:27Z")
> [@pmeunier](#):
>
> Changesets are great, especially since I don’t like the term “patch” very much.
> [@pmeunier](#):
>
> 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.
- _hunk_, _fragment_ → _change_
- _patch_, _commit_ → _changen_
- _patchset_, _branch_ → _changenset_
- 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 change **s** 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 _change **n** set_ (in lieu of _change **s** set_/_patchset_ or _branch_) to refer to a set of (only partially ordered [for dependencies], unique) _changen_ **s** 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](https://discourse.pijul.org/t/nested-grouping-of-commits/279/6) and edge::EdgeFlags addresses the conflict distinctions), the term _change **nn** _ 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](https://discourse.pijul.org/t/is-having-replace-a-sensible-idea/530)), and then the term _change **nn** set_ could be used when a _change **n** set_ (~_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.
---
### Author:  [@fyr](https://discourse.pijul.org/u/fyr)
#### Post date: [October 2, 2020, 2:52am UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/17 "2020-10-02T02:52:19Z")
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.)
---
### Author:  [@jeltsch](https://discourse.pijul.org/u/jeltsch)
#### Post date: [October 2, 2020, 11:09am UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/18 "2020-10-02T11:09:23Z")
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?
---
### Author:  [@pmeunier](https://discourse.pijul.org/u/pmeunier)
#### Post date: [October 2, 2020, 11:24am UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/19 "2020-10-02T11:24:30Z")
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.
---
### Author:  [@joyously](https://discourse.pijul.org/u/joyously)
#### Post date: [October 2, 2020, 5:48pm UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/20 "2020-10-02T17:48:23Z")
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.
---
### Author:  [@jeltsch](https://discourse.pijul.org/u/jeltsch)
#### Post date: [October 4, 2020, 5:30pm UTC](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276/21 "2020-10-04T17:30:12Z")
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”.
[Next page](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276.md?page=2)