The great rewrite of 2023

5 files changed, 0 insertions, 688 deletions

diff --git a/site/opinions/MonadTransformers.org b/site/opinions/MonadTransformers.org
deleted file mode 100644
index 22f4edd..0000000
--- a/site/opinions/MonadTransformers.org
+++ /dev/null
@@ -1,80 +0,0 @@
-#+TITLE: Monad Transformers are a Great Abstraction
-
-#+SERIES: index.html
-#+SERIES_NEXT: StackedGit.html
-
-This article has originally been published on @@html:<span
-id="original-created-at">@@July 15, 2017@@html:</span>@@. [[mn:doubts][Time has
-passed since the publication of this article. Whether or not I remain
-in sync with its conclusions is an open question. Monad Transformers
-are a great abstraction, but given the choice, I would probably choose
-another approach.]]
-
-#+BEGIN_EXPORT html
-<div id="history">site/opinions/MonadTransformers.org</div>
-#+END_EXPORT
-
-Monads are hard to get right. I think it took me around a year of Haskelling to
-feel like I understood them. The reason is, to my opinion, there is not such
-thing as /the/ Monad. It is even the contrary. When someone asks me how I would
-define Monads in only a few words, I say monads are a convenient formalism to
-chain specific computations. Once I’ve got that, I started noticing “monadic
-construction” everywhere, from the Rust ~?~ operator to the [[https://blog.drewolson.org/elixirs-secret-weapon/][Elixir ~with~
-keyword]].
-
-Haskell often uses another concept above Monads: Monad Transformers. This allows
-you to work not only with /one/ Monad, but rather a stack. Each Monad brings its
-own properties and you can mix them into your very own one. That you can’t have
-in Rust or Elixir, but it works great in Haskell. Unfortunately, it is not an
-easy concept and it can be hard to understand. This article is not an attempt to
-do so, but rather a postmortem review of one situation where I found them
-extremely useful. If you think you have understood how they work, but don’t see
-the point yet, you might find here a beginning of answer.
-
-Recently, I ran into a very good example of why Monad Transformers worth it. I
-have been working on a project called [[https://github.com/ogma-project][ogma]] for a couple years now. In a
-nutshell, I want to build “a tool” to visualize in time and space a
-storytelling. We are not here just yet, but in the meantime I have wrote a
-software called ~celtchar~ to build a novel from a list of files. One of its
-newest feature is the choice of language, and by extension, the typographic
-rules. This information is read from a configuration file very early in the
-program flow. Unfortunately, its use comes much later, after several function
-calls.
-
-In Haskell, you deal with that kind of challenges by relying on the Reader
-Monad. It carries an environment in a transparent way. The only thing is, I was
-already using the State Monad to carry the computation result. But that’s not an
-issue with the Monad Transformers.
-
-#+BEGIN_SRC diff
--type Builder = StateT Text IO
-+type Builder = StateT Text (ReaderT Language IO)
-#+END_SRC
-
-As you may have already understood, I wasn't using the “raw” ~State~ Monad, but
-rather the transformer version ~StateT~. The underlying Monad was ~IO~, because
-I needed to be able to read some files from the filesystem. By replacing ~IO~ by
-~ReaderT Language IO~, I basically fixed my “carry the variable to the correct
-function call easily” problem.
-
-Retrieving the chosen language is as simple as:
-
-#+BEGIN_SRC haskell
-getLanguage :: Builder Language
-getLanguage = lift ask
-#+END_SRC
-
-And that was basically it. The complete [[https://github.com/ogma-project/celtchar/commit/65fbda8159d21d681e4e711a37fa3f05b49e6cdd][commit]] can be found on Github.
-
-Now, my point is not that Monad Transformers are the ultimate beast we will have
-to tame once and then everything will be shiny and easy. There are a lot of
-other way to achieve what I did with my ~Builder~ stack. For instance, in an
-OO language, I probably would have to add a new class member to my ~Builder~
-class and I would have done basically the same thing.
-
-However, there is something I really like about this approach: the ~Builder~
-type definition gives you a lot of useful information already. Both the ~State~
-and ~Reader~ Monads have a well established semantics most Haskellers will
-understand in a glance. A bit of documentation won’t hurt, but I suspect it is
-not as necessary as one could expect. Moreover, the presence of the ~IO~ Monad
-tells everyone using the ~Builder~ Monad might cause I/O.
diff --git a/site/opinions/StackedGit.org b/site/opinions/StackedGit.org
deleted file mode 100644
index a53fd98..0000000
--- a/site/opinions/StackedGit.org
+++ /dev/null
@@ -1,344 +0,0 @@
-#+TITLE: How I Use Stacked Git at ~$WORK~
-
-#+SERIES: index.html
-#+SERIES_PREV: MonadTransformers.html
-#+SERIES_NEXT: StackedGit2.html
-
-According to [[https://lobste.rs/s/s6quvg/stacked_git][my Lobste.rs history]], I have run into [[https://stacked-git.github.io][Stacked Git]] in
-early April, 2021, and I remember its promises hit a soft spot.
-A few weeks later, I was submitting [[https://github.com/stacked-git/stgit/pull/100][a /pull request/ to teach Stacked
-Git to sign commits]].
-It was all I needed to start using it at ~$WORK~, and now it has
-become a cornerstone of my development workflow.
-
-#+BEGIN_EXPORT html
-<div id="history">site/opinions/StackedGit.org</div>
-#+END_EXPORT
-
-* What is Stacked Git?
-
-  Before going any further, it is probably a good idea to take a
-  moment and present Stacked Git.
-  The website introduces the tool as follows:
-
-  #+begin_quote
-  Stacked Git, *StGit* for short, is an application for managing Git
-  commits as a stack of patches.
-  #+end_quote
-
-  There is a few things to unpack here.
-  First and as its name suggests, Stacked Git is a tool built on top
-  of Git.
-  [[mn:pijul][My main takeaway from my Pijul adventure is connected to
-  this.  Git is not limited to the ~git~ binary.
-  Git comes with a collection of powerful forges, nice editor plugins,
-  and years of good practices.
-  To this day, it’s neither the bugs nor the breaking changes that
-  made me quite Pijul.
-  Those were expected.
-  What I naively did not anticipate is the dry feeling that Pijul was
-  just the ~pijul~ binary, which left me with a lot of tasks to do
-  manually.]]
-  It is *not* a brand new VCS, and as a consequence you keep to use
-  all your existing tools and plugins[fn::I am looking at you,
-  Magit.].
-  Secondly, Stacked Git helps you curate your Git history, by turning
-  your commits into patches, and your branches into stacks of patches.
-  This speaks to me, maybe because I have been fascinated by
-  email-based workflows for quite some time.
-
-  To me, the two core features of Stacked Git are (1) allowing you to
-  name your commits, and (2) to navigate among them.
-  Together, they create a wonderful companion to help you keep your
-  history clean.
-
-* My Subset of Stacked Git
-
- I do not want this article to be a Stacked Git tutorial.
- Fortunately, I don’t really use the tool at its full potential.
- I only care about a relatively small subset of commands I feel
- comfortable with and use daily.
-
- First, to decide which commits are part of my “stack of patches,” I
- can count of these commands:
-
- - ~stg new NAME~ creates an empty commit, and gives it the name
-   ~NAME~.
-   Having a way to identify a patch with a meaningful name that is
-   resistant to rebase and amend is very nice.
-   These are two properties commit hashes do not have.
- - ~stg uncommit NAME~ names the most recent commit under my
-   stack with ~NAME~ and integrates it into it. I do this when I am
-   tasked to work on a merge request made by a colleague, for
-   instance.
- - ~stg commit~ removes from my stack its last patch. I do this when
-   said commit has been merged into ~master~.
-
- Once my stack of patches is ready, the fun begins.
-
- At a given time, a patch can either be (1) applied, (2) unapplied,
- or (3) hidden.
- On the one hand, if a patch is applied it is part of the Git history.
- On the other hand, unapplying a patch means removing it from the
- working branch (but not from the stack of patches of Stacked Git).
- If a patch becomes unrelevant, but you don’t want to remove it
- entierely because it can become handy later, you can hide it.
- A hidden patch sits beside the stack of patches, and can be
- reintegrated if need be.
-
- Analoguous to ~git log~ ---which allows you to visualize your Git
- history---, ~stg series~ gives you a view the state of your stack of
- patches.
- Patches prefixed with ~+~ (or ~>~) are applied, while ~-~ means the
- patch is unapplied.
-
- Then,
-
- - ~stg pop~ unapplies the patch on top of the list of applied
-   patches.
- - ~stg push~ applies the patch on the bottom of the list of unapplied
-   patches.
- - ~stg goto NAME~ unapplies or applies the necessary patches so that
-   ~NAME~ becomes the top patch of the list of applied patches.
-
- ~HEAD~ and the worktree are updated accordingly.
-
- In addition, ~stg sink~ and ~stg float~ allow to reorganize your
- stack of patches, moving patches around.
- Basically, they are like ~git rebase -i~, but without having to use
- ~$EDITOR~.
-
- Modifying patches is done with ~stg refresh~.
- It’s akin to ~git commit --amend~, except it is more powerful because
- you can modify any applied patches with the ~-p~ option.
- I’d always encourage you to ~stg goto~ first, because ~stg refresh
- -p~ remains unfortunately error prone (nothing prevents you to target
- the wrong patch).
- But when used carefully, it can be very handy.
-
- [[mn:rebase][Stacked Git is supposedly able to detect, during a rebase,
- which of your patches have been applied to your target branch.
- I’d rather use ~stg uncommit~ before do the rebase, though.]]
- Finally, ~stg rebase REF~ moves your stack of patches on top of
- ~REF~.
- It is akin to ~git rebase --onto~, but more straightforward.
- What happens is Stacked Git pop all the patches of my stack, reset
- the ~HEAD~ of the current branch to ~REF~, and tries applying the
- patches one by one
- In case of conflicts, the process stop, and I am left with an empty
- patch, and a dirty worktree with conflicts to solve.
- The hidden gem is that, contrary to ~git rebase~, the repository is
- not “in the middle of a rebase.”
- Suppos there are many conflicting patches still waiting in my stack
- of patches, and an urgent task I need to take care of first.
- I can just leave them here.
- I can switch to another branch, and when I come back, I get my
- patches back.
- I call this feature “incremental rebases.”
-
- And that is basically it.
- In a nutshell, Stacked Git equips commits with the same features as
- branches.
-
-* My Stacked Git Workflow
-
-  As mentioned in the introduction of this article, Stacked Git has
-  become a cornerstone of my workflow.
-  I’ve been asked a few times what this workflow is, and why Magit is
-  not enough[fn::It’s always about Magit ;).].
-  So let’s try to do that.
-  But first, a warning.
-  Yes, because Stacked Git is only a wrapper above Git, everything I
-  will explain can be achieved using Git alone, especially if you are
-  a Magit wizard.
-
-  Stacked Git makes just everything so more convenient to me.
-
-** Planning My Commits Ahead Of Time
-
-   I’ve been introduced to Git with a pretty simple workflow: I am
-   supposed to start working on a feature, and once it’s ready, I
-   can commit, and move on to the next task on my todo list.
-
-   To me, this approach is backward.
-   It makes you set your intent after the fact.
-   With Stacked Git, I often try to plan my final history /before
-   writing the very first line of code/.
-   Using ~stack new~, I create my patches, and take the time to write
-   their description.
-   It helps me visualizing where I want to go.
-   Then, I use ~stack goto~ to go back to the beginning of my stack,
-   and start working.
-
-   It is not, and cannot be, an exact science. I often have to refine
-   them as my work progresses.
-   Yet, I think my Git history is cleaner, more focused, since I have
-   started this exercise.
-
-** Getting My Fixup Commits Right
-
-   Reviews are a fundamental aspect of a software developer job.
-   At ~$WORK~, we use Gitlab and their merge requests workflow,
-   which I find very annoying, because it does not provide meaningful
-   ways to compare two versions of your submission[fn::There is a
-   notion of “versions” in Gitlab, but its ergonomics fall short of my
-   expectations for such tool.].
-
-   What we end up doing is creating “fixup commits”, and we push them
-   to Gitlab so that reviewers can easily verify that their feedback
-   have correctly been taken into account.
-
-   A fixup commit is a commit that will eventually be squashed into
-   another.
-   You can understand it as a delayed ~git commit --amend~.
-   Git has some built-in features to manipulate them.
-   You create them with ~git commit --fixup=<HASH>~, and they are
-   interpreted in a specific manner by ~git rebase -i~.
-   But they have always felt to me like a sordid hack.
-   It is way too easy to create a fixup commit that targets the wrong
-   commit, and you can end up with strange conflicts when you finally
-   squash them.
-   That being said, if used carefully, they are a powerful tool to
-   keep a Git history clean.
-
-   I am not sure we are using them carefully, though.
-
-   Some reviews can be excruciating, with dozens of comments to
-   address, and theoretically as many fixup commits to create.
-   Then you push all of them on Gitlab, and days later, after the
-   green light from the reviewer, you get to call ~git rebase~
-   and discover your history is broken, you have tones of conflicts
-   to fix, and you’re good for a long afternoon of untangling.
-
-   The main reason behind this mess is that you end up fixing a commit
-   from the ~HEAD~ of your working branch, not the commit itself.
-   But with Stacked Git, things are different.
-   With ~stg goto~, I put my working tree in the best state possible
-   to fix a commit: the commit itself.
-   I can use ~stg new~ to create a fixup commit, with a meaningful
-   name.
-   Then, I am forced to deal with the potential conflicts it brings
-   when I call ~stg push~.
-
-   Once my reviewer is happy with my work, I can call ~stg squash~.
-   It is less automated than ~git rebase -i~, but the comfort I gained
-   during the development is worth this little annoyance.
-
-** Managing Stacked Merge Requests
-
-   At ~$WORK~, we are trying to change how we deliver new features to
-   our ~master~ branch.
-   More precisely, we want to merge smaller contributions more
-   frequently.
-   We have had our fair share of large and complex merge requests that
-   were a nightmare to review in the past, and it’s really not a fun
-   position to be put in.
-
-   For a few months, I have been involved in a project wherein we
-   decided /not/ to fall in the same trap again.
-   We agreed on a “planning of merge requests” and started working.
-   The first merge request was soon opened.
-   We’ve nominated a “owner” to take care of the review, and the rest
-   of the team carried on.
-   Before the first merge request was merged, the second one was
-   declared ready, and another owner was appointed.
-   Then, the owner of the first merge request had a baby, and yours
-   truly ended up having to manage two interdependent merge requests.
-
-   It turns out Stacked Git is a wonderful tool to help me keep this
-   under control.
-
-   I only have one branch, and I use the same workflow to deal with
-   feedbacks, even if they are coming from more than one one merge
-   request.
-   To remember the structure of everything, I just prefix the name of
-   my patches with a merge request nickname.
-   So my stack will look something like this:
-
-   #+begin_src
-   + mr1-base
-   + mr1-tests
-   + mr1-doc
-   > mr2-command
-   - mr2-tests
-   #+end_src
-
-   A reviewer leaves a hard-truth comment that requires a significant
-   rework of the oldest merge request?
-   ~stg goto~ reverts my worktree in the appropriate state, and ~stg
-   push~ allows me to deal with conflicts one patch at a time.
-   If at some point I need to spend more time on the oldest merge
-   request, I can continue my work, knowing the patches related to the
-   newest one are awaiting in my stack.
-
-   The most annoying part is when the time comes to push everything.
-   I need to ~stg goto~ at the last patch of each merge request, and
-   ~git push HEAD:the-branch~.
-   It’s not horrible.
-   But I will probably try to automate it at some point.
-
-* Grievances
-
-  Stacked Git have changed how I contribute to ~$SOFTWARE~ at ~$WORK~.
-  It makes my life so much easier, especially now that I am dealing
-  with stacked merge requests.
-  That being said, I still have some grievances I’d like to address at
-  some point, hopefully by contributing upstream.
-
-
-** Stacked Git Feels Slow
-
-  I suspect this is due to the conjunction of (1) ~$WORK~ repository
-  is large, and (2) Stacked Git is implemented in Python.
-  Maybe I am unfair, and the real causes lie somewhere else.
-  But the measurable fact I am witnessing is that ~stg series~ and
-  ~stg top~ (which prints the top patch name of the applied patches)
-  take 0.1s each.
-
-  It’s not an issue when you call them from the shell, but it is when
-  you use them in your prompt.
-  Which I do.
-  This brings an annoying latency to my every interaction with the
-  repository.
-
-** I’d Like ~stg abort~ Please
-
-   In this article, I have praised how Stacked Git allows for
-   its so-called ---by me--- incremental rebases.
-   However, the other side of the coin is that Stacked Git does not
-   have something analoguous to the ~--abort~ command-line argument
-   that you can pass to ~git cherry-pick~ and ~git rebase~.
-   Not really.
-
-   [[mn:doubts][I don’t want to be unfair to Stacked Git here. Maybe the
-   documentation of Stacked Git provides useful tips to deal with this
-   issue, and I have just overlooked it.]]
-   Stacked Git has a command called ~stg undo~, which can achieve this
-   to some extent.
-   But ~stg undo~ does not like conflicts.
-   When called after a conflicting ~stg push~, its output is not
-   really helpful.
-
-   #+begin_src
-   Error: Need to resolve conflicts first
-   stg undo: Command aborted (all changes rolled back)
-   #+end_src
-
-   The only way out that I am aware of is:
-
-   - ~git add~ the files with conflicts.
-   - ~stg refresh~ to fix recover.
-   - ~stg undo~, twice.
-
-I’d argue we have seen better UXs.
-
-* Conclusion
-
-  Overall, I am really thankful to Stacked Git’s authors!
-  Thank you!
-  You are making my interactions with Git fun and carefree.
-  You provide me some of the convenience of patch-based VCS like [[http://darcs.net][Darcs]]
-  and [[https://pijul.org][Pijul]], but without sacrificing the power of Git.
-
-  I encourage anyone to at least give it a try, and I really hope I
-  will be able to contribute back to Stacked Git in the near future.
diff --git a/site/opinions/StackedGit2.org b/site/opinions/StackedGit2.org
deleted file mode 100644
index 16eb974..0000000
--- a/site/opinions/StackedGit2.org
+++ /dev/null
@@ -1,121 +0,0 @@
-#+SERIES: index.html
-#+SERIES_PREV: StackedGit.html
-#+SERIES_NEXT: StackedGitPatchTheory.html
-
-#+TITLE: How I Keep Using Stacked Git at ~$WORK~
-
-One year ago, I have published an article summarizing
-[[./StackedGit.html][my experience using Stacked Git at ~$WORK~]]. Twelve months later,
-enough has changed to motivate a spin-off piece.
-
-* Stacked Git is /Fast/
-  Firstly, it is important to state that my main complain about
-  Stacked Git is now a thing of the past! Stacked Git does not feel
-  slow anymore, and far from it. This is because
-  [[https://github.com/stacked-git/stgit/discussions/185][Stacked Git 2.0 has been rewritten in Rust]]. While RiiR (/Rewrite it
-  in Rust/) is a running meme on the Internet, in this particular
-  case, the result is very exciting.
-
-  Thanks to the performance boost, my Zsh prompt does not take 0.1s to
-  appear!
-
-  Speaking of Zsh prompt, basically what I ended up displaying is
-  ~(<TOP PATCH NAME> <APPLIED PATCHES COUNT>/<PATCHSET SIZE> <HIDDEN
-  PATCHES COUNT)~. For instance, ~(fix-1337 1/2 3)~.
-
-  In case you want to take inspiration in my somewhat working
-  configuration, here is the snippet of interest.
-
-  #+begin_src sh
-local series_top="$(stg top 2> /dev/null)"
-local total="$(stg series 2> /dev/null | wc -l)"
-local hidden="$(stg series --hidden 2> /dev/null | wc -l)"
-
-if [[ "${total}" -gt 0 ]]; then
-    local not_applied="$(stg series | grep -E '^-' | wc -l)"
-    local applied="$(($total - $not_applied))"
-
-    if [[ -z "${series_top}" ]]; then
-        series_top="·"
-    fi
-
-    echo -n "(${status_color}${series_top} ${applied}/${total} ${hidden})"
-    echo -n "  ($(current_branch))"
-fi
-  #+end_src
-
-* Branchless Workflow
-  Last year, I was using Stacked Git on top of git branches. More
-  precisely, I had one branch for each (stack of) Merge Request. It
-  worked well, because my typical MR counted 3 to 4 commits in
-  average.
-
-  Fast forward today, and things have changed on this front too. In a
-  nutshell, I have become a “one commit per MR” maximalist of
-  sort[[mn:onecommit][It goes without saying that this approach comes
-  with its set of drawbacks too. During the past year, I’ve pushed
-  fairly large commits which could have been splitted into several
-  smaller ones, for the sake of keeping my “one commit per MR”
-  policy. I have also had to manage large stacks of MRs.]]. I find
-  this approach very effective to get more focused reviews, and to
-  reduce the time it takes for a given MR to be integrated into the
-  main branch.
-
-  My previous approach based on git branches did not scale well with
-  this new mindset, and during the course of the year, I stopped using
-  branches altogether[fn::I did not invent the branchless workflow, of
-  course.  After it was first published, someone posted a link to my
-  Stacked Git article on Hacker News, and [[https://news.ycombinator.com/item?id=29959224][*@arxanas* posted a comment
-  about ~git-branchless~]]. I tried the tool, and even if it never
-  clicked for me, I was really compelled by its core ideas. Similarly,
-  [[https://drewdevault.com/2020/04/06/My-weird-branchless-git-workflow.html][Drew
-  DeVault has published a complete article on its own branchless
-  workflow in 2020]].].
-
-  These days, I proceed as follows.
-
-  1. I name each patch after the branch to which I will push it on our
-     upstream Git remote.
-  2. 99% of the time, I push my work using ~git push -f upstream @:$(stg top)~
-  3. I created a small git plugin I called ~git-prepare~ which allows
-     me to select one of the patch of my current patchset using ~fzf~,
-     and which pops all other patches that are currently applied.
-
-  ~git-prepare~ is really straightforward:
-
-  #+begin_src sh
-#!/bin/sh
-patch=$(stg series -P | fzf)
-
-if [[ ! $? -eq 0 ]] ; then
-    exit $?
-fi
-
-if [ -n "$(stg series -A)" ]; then
-    stg pop -a
-fi
-
-stg push ${patch}
-  #+end_src
-
-  The main hurdle which I still need to figure out is how to deal with
-  stacked MRs. Currently, this is very manual. I need to remember
-  which commit belongs to the stack, the order and dependencies of
-  these commits, and I need to publish each commit individually using
-  ~stg push; git push @:$(stg top)~.
-
-  The pragmatic answer is definitely to come back to git branches /for
-  this particular use case/, but it's not the /fun/ answer. So from
-  time to time, I try to experiment alternative approaches. My current
-  intuition is that, by adopting a naming convention for my patches, I
-  could probably implement a thin tooling on top of Stacked Git to
-  deal with dependents commits.
-
-* Conclusion
-  Putting aside stacked MRs for now, I am really satisfied with my
-  workflow. It’s very lightweight and intuitive, and working without
-  Stacked Git now feels backward and clunky.
-
-  So I will take this opportunity to thank one more time Stacked Git’s
-  authors and contributors. You all are making my professional like
-  easier with your project.
diff --git a/site/opinions/StackedGitPatchTheory.org b/site/opinions/StackedGitPatchTheory.org
deleted file mode 100644
index c3099f2..0000000
--- a/site/opinions/StackedGitPatchTheory.org
+++ /dev/null
@@ -1,112 +0,0 @@
-#+SERIES: index.html
-#+SERIES_PREV: StackedGit2.html
-
-#+TITLE: Patch Dependencies for Stacked Git
-
-Every time I catch myself thinking about dependencies between
-changeset of a software project, the fascinating field of patch
-theories comes to my mind.
-
-A “patch theory” usually refers to the mathematical foundation behind
-the data model of so-called Patch-based DVCS like Darcs and
-Pijul. More precisely, a patch theory is an encoding of the state of a
-repository, equipped with operations (gathered in so-called patches,
-not to be confused with ~GNU diff~ patches) one can do to this
-state. For instance, my rough understanding of Pijul’s patch theory is
-that a repository is an oriented graph of lines, and a patch is a set
-of operations onto this graph.
-
-An interesting aspect of patch theory is that it requires a partial
-order for its patches, from which a Patch-based DVCS derives a
-dependency graph. In a nutshell, a patch /P/ depends on the patches
-which are responsible for the presence of the lines that /P/
-modifies.
-
-I have always found this idea of a dependency graph for the patches
-of a repository fascinating, because I though it would be a very
-valuable tool in the context of software development.
-
-I wanted to slightly change the definition of what a patch
-dependency is, though. See, the partial order of Darcs and Pijul
-focus on syntactic dependencies: the relation between lines in text
-files. They need that to reconstruct these text files in the file
-system of their users. As a software developers writing these text
-files, I quickly realized these dependencies were of little interest
-to me, though. What I wanted to be able to express was that a
-feature introduced by a patch /P/ relied on a fix introduced by a
-patch /P'/.
-
-I have experimented with Darcs and Pijul quite a bit, with this idea
-stuck in the back of my mind. At the end of this journey, I
-convinced myself[fn::I am not trying to convince you, per say. This is
-a very personal and subjective feedback, it does not mean someone else
-couldn't reach a different conclusion.] (1) this beautiful idea I
-had simply could not scale, and (2) neither I nor our industry is
-ready to give up on the extensive ecosystem that has been built on top
-of ~git~ just yet. As a consequence, my interest in Patch-based DVCS
-decreased sensibly.
-
-Until very recently, that is. I got reminded of the appeal of a
-dependency graph for changesets when I started adopted a Gitlab
-workflow centered around Stacked Git and smaller, sometimes
-interdependent MRs.
-
-A manually curated graph dependency for a whole repository is not
-practical, but what about my local queue of patches, patiently
-waiting to be integrated into the upstream repository I am
-contributing too?  Not only does it look like a more approachable
-task, it could make synchronizing my stacked MRs a lot easier.
-
-The workflow I have in mind would proceed as follows.
-
-- Stacked Git’s ~new~ and ~edit~ commands could be extended to let
-  developers declare dependencies between their patches. It would be
-  the commands’ responsibility to enforce the wellfoundness of the
-  dependency graph (/e.g./, prevent the introduction of cycles in the
-  graph, and maybe diamonds too[fn::At least in a first version. There
-  is definitely value in being able to work with two independent
-  patches in conjunction with a third one that needs them both. That
-  being said, our goal here is to organize our work locally, and if it
-  is made easier by declaring artificial dependency, this is a
-  pragmatic sacrifice I am personally willing to make.]).
-- The ~series~ command could be improved to display the resulting
-  dependency graph.
-- ~push~ and ~pop~ would automatically take care (pushing or popping)
-  of the selected patch(es) dependencies.
-- Ideally, Stacked Git would get a new command ~prepare <PATCH NAME>~
-  which would pop every patches applied, then only only push ~<PATCH
-  NAME>~ and its dependencies (in the reverse order). Developers could
-  fix conflicts if need be. That is, Stacked Git would not be
-  responsible for the consistency or correctness of the dependency
-  graph.
-- Stacked Git could get commands to detect potential issues with the
-  dependency graph specified by the developer (mostly consisting in
-  dry-run of ~prepare~ to check if it would lead to conflicts).
-
-Because what we want is semantic dependencies, not syntactic
-dependencies between patches, I really think it makes a lot of sense
-to completely delegate the dependencies declaration to the
-developer[fn::Further versions of Stacked Git could explore computing
-the dependency graph automatically, similarly to what Git does. But I
-think that if Darcs and Pijul told us anything, it's that this
-computation is far from being trivial.]. The very mundane example that
-convinced me is the ~CHANGELOG~ file any mature software project ends
-up maintaining. If the contribution guidelines require to modify the
-~CHANGELOG~ file in the same commit as a feature is introduced, then
-the patches to two independent features will systematically
-conflict. This does not mean, from my patch queue perspective, I
-should be forced to ~pop~ the first commit before starting to work on
-the second one. It just means that when I call ~stg prepare~, I can
-have to fix a conflict, but fixing Git conflicts is part of the
-job after all[fn::And we have tools to help us. I wonder to which extends
-~git rerere~ could save the day in some cases, for instance.]. If for
-some reasons solving a conflict proves to be too cumbersome, I can
-always acknowledge that, and declare a new dependency to the
-appropriate patch. It only means I and my reviewers will be
-constrained a bit more than expected when dealing with my stack of
-MRs.
-
-I am under the impression that this model extends quite nicely the
-current way Stacked Git is working. To its core, it extends its data
-model to constraint a bit ~push~ and ~pop~, and empowers developers to
-organize a bit its local mess.
diff --git a/site/opinions/index.org b/site/opinions/index.org
deleted file mode 100644
index 2fe3e39..0000000
--- a/site/opinions/index.org
+++ /dev/null
@@ -1,31 +0,0 @@
-#+TITLE: Opinions
-
-I may have some opinions on some topics, and sometimes I may want to share
-them. However, I strongly believe facts and opinions are two differents things,
-and even though I do not intend to write plain wrong facts, I prefer to keep two
-separate indexes.
-
-I would encourage you to use your critical mind while reading these write-ups.
-
-** 2023
-
-   - [[./StackedGitPatchTheory.org][Patch Dependencies for Stacked Git]] ::
-     Could patch dependencies could help reduce the friction my
-     branchless workflow suffers from when it comes to stacked MRs?
-
-   - [[./StackedGit2.org][How I Keep Using Stacked Git at ~$WORK~ in 2023]] ::
-     One year has passed, and I keep using Stacked Git almost
-     daily. /How/ I am using it has slightly changed, though.
-
-** 2022
-
-   - [[./StackedGit.org][How I Use Stacked Git at ~$WORK~]] ::
-     I’ve been using Stacked Git at ~work~ since early 2021, and as
-     of January 2022, it has become a cornerstone of my daily
-     workflow.
-
-** 2017
-
-- [[./MonadTransformers.org][Monad Transformers are a Great Abstraction]] ::
-  Monads are hard to get right, monad transformers are harder. Yet, they remain
-  a very powerful abstraction.