data-separator-vertical="^\r?\n---\r?\n$">
            </section>
            <section data-markdown="sections/4-comparison.md" data-separator="^\r?\n------\r?\n$"

<!-- .slide: data-background="img/background/usb-sticks.jpg" data-background-color="black" data-background-opacity="0.3"-->
# Comparison
* Tabel die features met Git vergelijken
note:
**Time Elapsed:** 14 min.

There's a lot to like about Git:

Well, that's understandable!
Because there's a lot to like about Git:

* distributed nature (open-source development, work offline)

* distributed nature (open-source development, work offline)

Do we like...

Do we like... for example...

* running a diff when nothing happens?

* running a diff when nothing happens? (`--staged`)

* getting the same conflicts multiple times when dealing with long-lived branches?
* fresh clones because the repo is too messed up to repair?

* getting the same conflicts over and over again when we need long-lived branches?
* having to do a fresh clone because the repo is too messed up to repair?

Well... not particularly!

# Teaching a Git course

Sure enough, after 2005-2006, nothing seems to have happened in version control world.

Sure enough, after 2005, nothing seems to have happened in version control world.

And because I didn't know the answer to her question, I started researching it and found a few newer version control systems.
They were called Fossil and Pijul.
This talk is about Pijul, and how its approach is different from Git's approach.

And because I didn't know the answer to her question, I started researching it and found a newer version control systems.
It was called Pijul.
This talk is about Pijul, and how it's different from Git.

So let's address the name first.
...

So let's address the name of this version control system first.
[explain the name]

    <li class="fragment fade-in-then-semi-out">written in Rust
    <li class="fragment fade-in-then-semi-out">bootstrapped since April 2017
    <li class="fragment fade-in-then-semi-out">free code hosting at 

    <li>written in Rust
    <li>bootstrapped since April 2017
    <li>free code hosting at 

Like IntelliJ, they 'eat their own dog food'.

So they 'eat their own dog food'.

    <li class="fragment fade-in-then-semi-out">No merges or rebases; applying a patch is like <code>git cherry-pick</code>.</li>

    <li class="fragment fade-in-then-semi-out">No rebases, and merges are hardly needed; applying a patch is like <code>git cherry-pick</code>.</li>

Let's zoom in on this "patch-oriented design".
[walk through the bullet list]

---
## If commits were bank transactions
<table>
        <tr>
            <th/>
            <th>snapshot</th>
            <th>patch</th>
        </tr>
        <tr class="fragment">
            <th align="right">initial balance</th>
            <td align="right"><code>100</code></td>
            <td align="right"><code>+100</code></td>
        </tr>  
        <tr class="fragment">
            <th align="right">salary</th>
            <td align="right"><code>400</code></td>
            <td align="right"><code>+300</code></td>
        </tr>
        <tr class="fragment">
            <th align="right">heating</th>
            <td align="right"><code>0</code></td>
            <td align="right"><code>-400</code></td>
        </tr>
</table>
note:
Snapshots store account balance, patches store deltas.
Which means patch order doesn't matter for the final result.

note:
**Time Elapsed:** 6 min.
---

## Demo

**Time Elapsed:** 6 min.

# Wrap-up

## When To (Not) Use Pijul

# Now what?

<section>
        <h2>Now what?</h2>
        <ul>
        <li class="fragment">Git's snapshotting might be too technical for the average user. <strong>So try Pijul for a change!</strong></li>
        </ul>
        <aside class="notes">
        <strong>Time Elapsed: 15 min.</strong>

note:
**Time Elapsed:** 14 min.

        1. A lot of students in my "Git for developers" course are managers, test specialists, requirements engineers, Scrum Masters. And they struggle with Git's snapshot-based approach. Perhaps a patch-based approach like Pijul will suit them better.
</section>

---

note:

## When Do I Use Pijul?

**Time Elapsed:** 15 min.

* For a hobby project, so you can get the feel of it <!-- .element: class="fragment fade-in-then-semi-out" data-fragment-index="1" -->
* If your team members currently struggle with Git <!-- .element: class="fragment fade-in-then-semi-out" data-fragment-index="2" -->
* If you spend too much time on rebasing, merging and conflict resolution <!-- .element: class="fragment fade-in-then-semi-out" data-fragment-index="3" -->
* If you can self-host or use the Pijul Nest <!-- .element: class="fragment fade-in-then-semi-out" data-fragment-index="4" -->
**Try Pijul for a change!** <!-- .element: class="fragment fade-in-then-semi-out" data-fragment-index="5" -->
<https://pijul.org/manual/working_with_others.html> <!-- .element class="attribution fragment" data-fragment-index="4" -->
note: 
A lot of students in my "Git for developers" course are managers, test specialists, requirements engineers, Scrum Masters. And they struggle with Git's snapshot-based approach. Perhaps a patch-based approach like Pijul will suit them better.
---