# Patch based version control

**URL:** <https://discourse.pijul.org/t/patch-based-version-control/513>\
**Category:** Development\
**Created:** [July 20, 2020, 10:39pm UTC](https://discourse.pijul.org/t/patch-based-version-control/513 "2020-07-20T22:39:50Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![joyously](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/joyously/32/266_2.png) [@joyously](https://discourse.pijul.org/u/joyously)\
**Post date:** [July 20, 2020, 10:39pm UTC](https://discourse.pijul.org/t/patch-based-version-control/513/1 "2020-07-20T22:39:50Z")

</div>

Continuing the discussion from [Random Talks and Thoughts](https://discourse.pijul.org/t/random-talks-and-thoughts/29/5):

> [@Random Talks and Thoughts](https://discourse.pijul.org/t/random-talks-and-thoughts/29/5):
>
> I very much like the idea of patch based version control; I am not a dumb person but find it hard to imagine what git is doing, when I enter git commands such as found from the web (non-intuitive commands). My question here, is even more basic as the difference between patch based and snapshot based version control : Suppose one has a source code file that contains a loop and a counter in that loop has been forgotten to be incremented, and it does not really matter where in the loop body that counter gets incremented when that gets corrected, as long as, say it is the second half of that loop body (for sake of this discussion). Now suppose person A develops a patch AA in which counter gets incremented right in middle of loop body and person B develops a patch BB in which counter gets incremented at end of loop body. Now _as there is no conflict of lines_ it appears as if both patches can be merged without conflict. However, then, the counter gets incremented twice. This is a fundamental problem of automatic merging.

I have never felt comfortable with Git. I have used Bazaar, and I recently reread an [article](https://duckrowing.com/2013/12/26/bzr-init-a-bazaar-tutorial/) explaining how the history is shown differently in Git, Mercurial, and Bazaar. That article claims

> I’d differentiate Git from other DVCS systems by saying it’s _patch oriented_. The goal of Git is to arrive at some patch that describes the next state in a project- tracking history is viewed as not as important as tracking the patch or the content.

I guess that’s why I’m still not sure what to make of Pijul. It sounds great to be able to apply patches in different orders, but the main point of “version control” is to be able to get at the different versions easily, able to refer to a version in terms of a release, able to list what is in a version. This seems easier with a snapshot. Maybe that’s just my feeble mind not able to hold all the possibilities, but I’m used to seeing files and comparing one to another to see the changes.  
It might be that Pijul does this, and even in an easy way, but so far, as a new user, I can’t tell.  
What made sense to me was later in that article,

> For lack of a better term, Bazaar is _branch oriented_. Both git init and hg init create new repositories. However, bzr init _creates a new branch_. Both git clone and hg clone create copies of repositories. The equivalent command in Bazaar, bzr branch _forks a new branch_. Both git log and hg log examine the history of the repository. The bzr log command shows _branch history_.  
> It’s a very subtle change in point of view. Bazaar elevates branches to the primary metaphor, relegating the concept of repository to more of a background player role.

Perhaps this makes sense because I’m used to working with files, and having another branch is another copy of the files. With that reflected in the log, there’s nothing to figure out.

The question is: Is Pijul far enough away from what Git does to fix all its problems or is it just addressing one area of concern?

---

<div class="post-metadata">

**Author:** ![artis](https://avatars.discourse-cdn.com/v4/letter/a/9fc348/32.png) [@artis](https://discourse.pijul.org/u/artis)\
**Post date:** [July 21, 2020, 5:40pm UTC](https://discourse.pijul.org/t/patch-based-version-control/513/2 "2020-07-21T17:40:34Z")

</div>

To best answer that question its important to understand where exactly you are coming from. Based on the quote article you refer to I infer that you are mainly thinking in terms of the Git/Mercurial/Bazaar when reasoning about version control in general. Is that the case and if so, do you mind me retreading some ground you may find very familiar to ensure we are on the same page?

Edit: Also, would it be fair to say that your main use of version control is to refer back to the changes you have made rather than to collaborate with a lot of other people? That’s where I’m coming from as a former user of Bazaar.

---

<div class="post-metadata">

**Author:** ![joyously](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/joyously/32/266_2.png) [@joyously](https://discourse.pijul.org/u/joyously)\
**Post date:** [July 21, 2020, 7:19pm UTC](https://discourse.pijul.org/t/patch-based-version-control/513/3 "2020-07-21T19:19:48Z")

</div>

> [@artis](#):
>
> where exactly you are coming from

I think it shouldn’t matter what a person’s background is. Version control should live up to its name and track versions, whether that is software releases or departmental progress.

My main use is open source software, like WordPress, which uses a mix of SVN and Git. I prefer Bazaar for my own projects, and it makes sense as an Ubuntu user. Last year, I was trying to review pull requests for a collaboration(the WordPress Twenty Twenty theme) on GitHub. I had a very difficult time trying to figure out what was what and how to test them. There was always a need to refresh from master before they could be dealt with and that seemed to pollute the “patch”, making it look like the changes in master were actually submitted in the PR. This might just be how GitHub conveys the information, and not Git itself, but if you didn’t make the change yourself, it’s so hard to see what’s going on. That is my main concern with any VCS.

One of the small projects I had was to enhance someone else’s code that has been abandoned. I tried to make a GitHub repo by giving it the SVN URL, and that only partially worked. It resulted in a repo of version 1.5 instead of the 4.3 that I gave it. But I didn’t see how I could then add in to Git the changes I had made some years before, as a new version, with the old date. (I was trying to share my changes so a client could see the whole history as it really happened, and I needed new changes on top of that.)

---

<div class="post-metadata">

**Author:** ![artis](https://avatars.discourse-cdn.com/v4/letter/a/9fc348/32.png) [@artis](https://discourse.pijul.org/u/artis)\
**Post date:** [July 21, 2020, 11:05pm UTC](https://discourse.pijul.org/t/patch-based-version-control/513/4 "2020-07-21T23:05:45Z")

</div>

> [@joyously](#):
>
> I think it shouldn’t matter what a person’s background is.

That came out wrong, sorry. I only meant inquire specifically about your familiarity with version control software and the rest of your reply gives me a reasonably good idea.

First off I should clarify both my understanding of a few terms as they relate to VCS and in particular DVCS.

- version: the contents of a file or folder structure at any given moment
- snapshot: a record that enables to completely reproduce a specific version
- patch: a full description of the differences between any two versions
- VCS: a program that can store and reproduce specific versions
- DVCS: a VCS that allows multiple people to independently store versions

> [@joyously](#):
>
> […] the main point of “version control” is to be able to get at the different versions easily, able to refer to a version in terms of a release, able to list what is in a version.

The ability to record and restore versions is the very core functionality of a VCS. _Every_ VCS has some notion of snapshots regardless of how it processes versions internally.

> [@joyously](#):
>
> This seems easier with a snapshot. Maybe that’s just my feeble mind not able to hold all the possibilities, but I’m used to seeing files and comparing one to another to see the changes.

Most of the time you should not have to worry about the precise ways in which a VCS reproduces a version, _especially_ if you are the only one making changes. What you care about is recording changes, reviewing other versions (snapshots) and comparing versions (patches). The rest is outright counter intuitive and you should _not_ feel bad being confused.

The difficult bit is dealing with independent changes in the same exact place in a file. It is so difficult that for the longest time the solution was to prevent the recording of any independent changes. For individuals this didn’t cause any problems to speak of, small teams working together closely could coordinate to work around the problem. Large groups of people working on the same project with little to no contact for long periods were not much worse off just making copies by hand because as you noted, snapshots are easier.

The Git/Mercurial/Bazaar wave of DVCS is essentially just automating the process of periodically taking snapshot after snapshot from each developer, comparing each of those snapshots to what you have _one by one_ and combining them _when and if_ need to. Depending on what you are working on you may incorporate recent changes before much folders ones, which is why ordering changes by time doesn’t really work with DVCS.

Large teams have to compare different versions all the time and apply changes from one snapshot to another, which is the extent of the “patch oriented” nature of those systems. The main difference between Bazaar and Git is that it doesn’t expose any of the complexity when you are working on your own and even makes it _relatively_ easy to work on multiple different things in parallel on your own, although you still have to eventually apply each branch _one at a time_ when you want to make it all work together.

The problem that Pijul tries to address is dealing with each separate snapshot as a separate version. Being able to combine patches in any order means you are no longer applying them one at a time. Furthermore, it means that it does not matter how anyone else did it as long as you get the same result. Does it help when working on your own?

That depends. When your changes can go in any order you can work on different areas in any order without having to figure out the right branch for each area before you have even started.

---

<div class="post-metadata">

**Author:** ![no\_identd](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/no_identd/32/126_2.png) [@no\_identd](https://discourse.pijul.org/u/no_identd)\
**Post date:** [July 22, 2020, 3:09pm UTC](https://discourse.pijul.org/t/patch-based-version-control/513/5 "2020-07-22T15:09:32Z")

</div>

Pijul supports patching of patches, no? This seems to represents one more path along which feature separation/branching may occur, and one I haven’t seen discussed in this thread yet.

---

<div class="post-metadata">

**Author:** ![no\_identd](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/no_identd/32/126_2.png) [@no\_identd](https://discourse.pijul.org/u/no_identd)\
**Post date:** [July 22, 2020, 3:44pm UTC](https://discourse.pijul.org/t/patch-based-version-control/513/6 "2020-07-22T15:44:49Z")

</div>

Welp, so much for that idea. Why? Cuz:

> [@Nested grouping of commits?](https://discourse.pijul.org/t/nested-grouping-of-commits/279/6):
>
> I don’t want that feature anymore. Two improvements have made it redundant: (1) a canonical text representation of patches in the new Pijul, and (2) arbitrary metadata fields in the patches.

---

<div class="post-metadata">

**Author:** ![joyously](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/joyously/32/266_2.png) [@joyously](https://discourse.pijul.org/u/joyously)\
**Post date:** [July 22, 2020, 9:26pm UTC](https://discourse.pijul.org/t/patch-based-version-control/513/7 "2020-07-22T21:26:33Z")

</div>

I’m not sure what question you are trying to answer, but it doesn’t seem to be the one I’m asking, which is:

> [@joyously](#):
>
> The question is: Is Pijul far enough away from what Git does to fix all its problems or is it just addressing one area of concern?

---

<div class="post-metadata">

**Author:** ![artis](https://avatars.discourse-cdn.com/v4/letter/a/9fc348/32.png) [@artis](https://discourse.pijul.org/u/artis)\
**Post date:** [July 23, 2020, 12:46am UTC](https://discourse.pijul.org/t/patch-based-version-control/513/8 "2020-07-23T00:46:44Z")

</div>

If that was the only thing you had written I would not have attempted to answer as the question by itself is simply too vague. However you brought up a number of issues pertaining to Git’s problems. If everything you added before the question was not there to narrow it down then I can’t really help. Sorry.