<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>

    <li class="fragment fade-in-then-semi-out">Rebase and merge don't exist, applying a patch (and its dependencies) is like <code>git cherry-pick</code>.</li>

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

In Git each snapshot has its own identity. 
[on **order**]
Changes in Pijul can be applied in any order. This is great for cherry-picking: Pijul knows the changes that need to come along, and maintains the identity of the change after the cherry-pick. No need to manually find the commits to revert or pick.
[on **rebase** and **merges**]
One particular goal of Pijul is to model conflicts as normal states of collaboration, so that conflicts are resolved by normal changes, valid even for the same conflicts in any other context.
It is important to note that conflicts in Pijul always happen between changes, for example we might say that “change A conflicts with change B”. A conflict resolution is always a change. 

One of the main features of Pijul is that its internal representation of repositories fully models conflicts. Patches can even be applied to a conflicting repository, leaving the conflict resolution for later.

---
## 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.

---

<img data-src="img/logos/future-tech.png" width="15%" class="no-background"/>

<img data-src="img/logos/frontmania.png" width="25%" class="no-background"/>

(and who doesn't like these handraising questions?)

(and who doesn't like these stupid handraising questions?)

    <link rel="stylesheet" href="css/future-tech.css" id="custom">

    <link rel="stylesheet" href="css/frontmania.css" id="custom">

                        </li>
                        <li class="fragment fade-in-then-semi-out">Try out Pijul @ katacoda.com
                            <br /><small><a
                                    href="https://www.katacoda.com/ysndr/scenarios/pijul">https://www.katacoda.com/ysndr/scenarios/pijul</a></small>

                <a href="https://twitter.com/hannotify">#FutureTech #SuccessorOfGit</a>

                <a href="https://twitter.com/hannotify">#FrontMania #SuccessorOfGit</a>

## Program & target times
| Section | Target time | Duration |
|---|---:|---:|
| Welcome | 0:00 | 3:00 |
| Preface | 3:00 | 5:00 |
| Git | 8:00 | 5:00 |
| The browser wars | 13:00 | 4:00 |
| New kids on the block | 17:00 | 1:00 |
| Fossil | 18:00 | 9:00 |
| Pijul | 27:00 | 13:00 |
| Predictions | 40:00 | 15:00 |
| Wrap-up | 45:00 | 0:00 |