[_ikke_]

Until you want to introduce a change that affects both machines. You need to start rewriting history or cherry-pick the changes on both branches. The further the history diverges, the harder this becomes.

Using branches for this does not scale.

[lillecarl]

This is where a VCS like Pijul or Darcs would shine, since patches commute across "branches" without a new hash.

[gravescale]

How does that work if there's a conflict? Whether or not there's a hash involved, you still have to manually apply the patch to each branch, would you not? If there's no conflict, merging each branch up in git is not hard at all, but it's still a tedious extra 'n - 1' operations that you don't need in chezmoi.

For example, say I have a line "export FOO=bar" in my .bashrc on one machine and "export FOO=baz" on another. If I then indent the line on the bar branch and try to merge to the other one, something has to tell the baz branch that the right line is both differences: " export FOO=baz". Except the conflict may not be so obvious to resolve as that! And whatever you do, you'll either have a "trellis" of 'n' branches if you merge, or 'n' parallel linear branches if you cherry pick everything. Both of those history layouts quickly become very hard (to me at least) to make sure they all contain everything they should and nothing they shouldn't.

Whereas with chezmoi, the bashrc file is a template that is the same on all machines that simply says "export FOO={{ fooval }}" and chezmoi does the templating. So you can just indent the line and fast-forward/apply on other machines and that's it.

[lillecarl]

It's not intended as a dotfile manager replacement, but a Git replacement.

As long as the patches don't conflict its fine and dandy, if there's a collision you record a resolution that fixes the conflict

[pmeunier]

Also, the conflict resolution is just another patch (Pijul patches aren't just regular diffs, they have a lot more information), so should you decide to merge it back upstream after all, you can also cherry-pick the conflict resolution along with the conflicting patch, and also without changing the hash.

[pmeunier]

One of the motivations behind Pijul was to manage custom versions of Nixpkgs while still benefiting from upstream commits. One issue that's hard with Git is that when you also want to contribute multiple changes back, you have:

1. A branch pointing to the latest nixpkgs head.

2. A branch with commit A (let's say commit A introduces a new package to nixpkgs).

3. A branch with commit B (changing some config file).

4. A branch currently at in use for your own machines, with branches 2 and 3 rebased on top of branch 1.

Every time you do anything, you'll have to remember the flow for getting the commits fetched/rebased. Which is fine if you have a DevOps team doing exactly that, but isn't too cool if you are anything other than a large company.

In Pijul, you would have a single channel (branch sort-of equivalent) and two patches (A and B) instead, which you can push independently from each other at any time if you want to contribute them back.

Darcs does the same but wouldn't scale to Nixpkgs-sized repos.

[Ferret7446]

I have no idea what you're talking about. You just merge the change.