# Calling branches "branches" is misleading **URL:** \ **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:** 1\ **Showing post:** 16

**Author:** ![brandon](https://avatars.discourse-cdn.com/v4/letter/b/f08c70/32.png) [@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. --- _[View the full topic](https://discourse.pijul.org/t/calling-branches-branches-is-misleading/276)._