# Surprising behaviours

**URL:** <https://discourse.pijul.org/t/surprising-behaviours/736>\
**Category:** Question\
**Created:** [February 20, 2021, 6:00pm UTC](https://discourse.pijul.org/t/surprising-behaviours/736 "2021-02-20T18:00:52Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![unidual](https://avatars.discourse-cdn.com/v4/letter/u/91b2a8/32.png) [@unidual](https://discourse.pijul.org/u/unidual)\
**Post date:** [February 20, 2021, 6:00pm UTC](https://discourse.pijul.org/t/surprising-behaviours/736/1 "2021-02-20T18:00:52Z")

</div>

Hi, new(b) here! Mathematician at heart, I’m very inclined to (ab)use `pijul`.

Here is some feedback I have about unexpected or unintuitive behaviours (in my book).  
Well, maybe I was just confused by workflows descriptions intended to the previous incarnation of `pijul`.

That’s the first issue: it’s hard to decipher what has become obsolete or even erroneous advice.

I love the cherry picking potential of the patch approach. E.g. to have a custom set of features, to activate or deactivate easily experimental and debugging patches, etc. But then I was a bit surprised:

- After `pijul record`, the directory is still in the same state. Well, the opposite would be even more surprising! But as I understand it, that means the patch is applied. So, I expected:
  - a message about that.
  - the possibility to unapply.  
Also, I’m not sure what the log is showing. I’d like to see all patches, where the applied ones would be highlighted.

The goal was to get the directory in a previous state, yet still having the patch available to re-pick it at will. I am not sure of how to do that confidently without losing my changes!

Other surprise: at some point I did `pijul add .` (note the dot), but it ended including files from parent directory (according to the record message).  
I removed the hunks I didn’t want from the message. But they were still included in the record.

So I tried an other approach: unrecord, and added explicitly the files I wanted in this particular record.  
Then `pijul diff --short` shows all modified files (No way to see which one will be included in the record).  
Plus, when recording again, the message was gone.

Suggestion:

- Could commit be made an alias for record? This would be more welcoming to long time git users. Possible mitigation:

- An undo command, which would exactly cancel any previous non-undo command (`redo` to undo the undo!).  
I’m still baffled no CVS offers that. Well, if the internal history is modified, that’s harder, unless having a meta-history (and turtles all the way down).

Hoping these remarks will be useful, I thank you for your work and the ability to have a sane git alternative or a fast darcs one!

Yves

---

<div class="post-metadata">

**Author:** ![pmeunier](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/pmeunier/32/4_2.png) [@pmeunier](https://discourse.pijul.org/u/pmeunier)\
**Post date:** [February 20, 2021, 6:40pm UTC](https://discourse.pijul.org/t/surprising-behaviours/736/2 "2021-02-20T18:40:22Z")

</div>

Thanks for such a detailed list of suggestions! This is very helpful. The whole thing is a mess at the moment, because I’ve been caught in a massive invisible change, supposed to make Pijul at least five times faster, but at the cost of changing the data representation.

In particular, I love your suggestions about messages, and it would be really helpful if you could copy-paste them as separate discussions on [nest.pijul.com/pijul/pijul/discussions](http://nest.pijul.com/pijul/pijul/discussions).

> [@unidual](#):
>
> the possibility to unapply.

You can use `pijul unrecord HASH`, where `HASH` is the hash given at the end of `pijul record`.

> [@unidual](#):
>
> Could commit be made an alias for record?

I’m afraid that could be more welcoming for Git beginners, but has a high confusion potential for advanced Git users, since they would start to believe that patches and commits are the same thing, and could get the wrong mental model. This isn’t a major problem, because you can simulate the behaviour of Git inside Pijul, but you would probably not benefit from Pijul very much if you did that (you’d just get Git + predictable merges and clean conflict resolutions).

For the same reason, we renamed “branches” to “channels” recently, to avoid the same kind of confusion (feature branches in Git are closer to “changes” in Pijul, while long-term branches in Git are closer to channels in Pijul).

Note that Darcs (a major source of inspiration for Pijul) didn’t have branches, so we’re still figuring out when branches are useful and when they aren’t.

---

<div class="post-metadata">

**Author:** ![kaspar030](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/kaspar030/32/306_2.png) [@kaspar030](https://discourse.pijul.org/u/kaspar030)\
**Post date:** [February 20, 2021, 10:30pm UTC](https://discourse.pijul.org/t/surprising-behaviours/736/3 "2021-02-20T22:30:39Z")

</div>

> [@pmeunier](#):
>
> you can simulate the behaviour of Git inside Pijul, but you would probably not benefit from Pijul very much if you did that (you’d just get Git + predictable merges and clean conflict resolutions).

IMO that wouldn’t be so bad. Especially if git users could start using Pijul as a drop-in replacement for the usual git workflows, but the road to using more advanced Pijul features is still open.

---

<div class="post-metadata">

**Author:** ![unidual](https://avatars.discourse-cdn.com/v4/letter/u/91b2a8/32.png) [@unidual](https://discourse.pijul.org/u/unidual)\
**Post date:** [February 20, 2021, 10:38pm UTC](https://discourse.pijul.org/t/surprising-behaviours/736/4 "2021-02-20T22:38:59Z")

</div>

Thanks for the quick and informative answer, really appreciated!

Fair enough for record vs commit. Backward pseudo-compatibility is a plague!  
That being said, i think the model is similar regarding the patches: an isolated change we want to annotate/explain. And the workflow should be very similar too: make changes (ideally with respect to only one aspect), pack your changes (that is, record/commit them), repeat.  
What differs is the repository state: sequence of patches vs set of (augmented) patches.  
But even there, we tend to reason in term of snapshot. E.g.: I want to go back at the time of this particular patch, before the psilocybin started kicking it. I don’t really care which older patches it depends on.  
That being said, that is very sweet that the a new channel doesn’t pull the entire history!  
Or maybe i was just brain-washed?

> [@pmeunier](#):
>
> You can use `pijul unrecord HASH` , where `HASH` is the hash given at the end of `pijul record` .

I’ve seen that, but as said we lose the record message. Worse, that’s not what I need! I don’t want the patch applied at all in the working dir.  
The use case here is to have some patches (e.g. old school print debugging, experimental variants) to switch on/off very easily. Like git stash or mercurial queue.  
If the only way is to create a different channel, we lose the combinatorial advantage of independent patches. What am I missing here?

> [@pmeunier](#):
>
> it would be really helpful if you could copy-paste them as separate discussions

Will do!

---

<div class="post-metadata">

**Author:** ![pmeunier](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/pmeunier/32/4_2.png) [@pmeunier](https://discourse.pijul.org/u/pmeunier)\
**Post date:** [February 21, 2021, 7:17am UTC](https://discourse.pijul.org/t/surprising-behaviours/736/5 "2021-02-21T07:17:10Z")

</div>

> [@unidual](#):
>
> I’ve seen that, but as said we lose the record message. Worse, that’s not what I need! I don’t want the patch applied at all in the working dir.

Sorry, I misunderstood your suggestion. One way to do that is that `pijul diff` outputs the same format as `pijul record`, and doesn’t apply the patch, so you could pipe that into patch files somewhere (maybe a new `.pijul/stash` directory?), and apply/unrecord them using `pijul apply`/`pijul unrecord`. The semantics of `pijul apply` is a bit confusing, IIRC it expects a patch in text format on the standard input.

> [@unidual](#):
>
> If the only way is to create a different channel, we lose the combinatorial advantage of independent patches. What am I missing here?

I don’t think you would miss that, channels are just sets of patches. If you create a `debugging` channel with your old school messages, this clones your patches from `main`. You can then record your debugging patches in the `debugging` channel, switch back to `main`, continue your work. Every time you want to switch again, you can push to `debugging` (`pijul push . --to-channel debugging`).

---

<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:** [February 21, 2021, 3:18pm UTC](https://discourse.pijul.org/t/surprising-behaviours/736/6 "2021-02-21T15:18:22Z")

</div>

I’m struggling to understand the point of channels. In this example, wouldn’t it make more sense to clone the repo into a new folder and apply the change? What benefit does a channel give you? Doesn’t it clutter the repository? Or is it really more like tags, preserving a snapshot of a certain state?

---

<div class="post-metadata">

**Author:** ![pmeunier](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/pmeunier/32/4_2.png) [@pmeunier](https://discourse.pijul.org/u/pmeunier)\
**Post date:** [February 21, 2021, 3:37pm UTC](https://discourse.pijul.org/t/surprising-behaviours/736/7 "2021-02-21T15:37:37Z")

</div>

> [@joyously](#):
>
> In this example, wouldn’t it make more sense to clone the repo into a new folder and apply the change?

Not necessarily. Darcs does that, at a great cost in terms of time and disk space. Channels can be used for many things, including indeed an efficient way to pinpoint a version (as you said, although that will be a bit redundant with tags, which are another representation of channels).

One major use case for Pijul was my use of nixpkgs, of which I’ve run a customised version for some times on a server, at the same time as contributing to their Git repository. That forced me to merge and rebase stuff often, and maintain multiple branches, but the lack of commutation + lack of identity of commits between the different branches + very long review time (Nix was a small community at the time) was annoying.

---

<div class="post-metadata">

**Author:** ![unidual](https://avatars.discourse-cdn.com/v4/letter/u/91b2a8/32.png) [@unidual](https://discourse.pijul.org/u/unidual)\
**Post date:** [February 21, 2021, 5:15pm UTC](https://discourse.pijul.org/t/surprising-behaviours/736/8 "2021-02-21T17:15:44Z")

</div>

What I meant is that if I have `N` patches I wish to play with, I don’t want to create `2^N` channels with all possible combinations!

I guess your suggestion could work:

- `record + unrecord + diff > ~/.patch/ouli + reset` to create such a patch and shelve it.
- `apply < ~/.patch/ouli` to unshelve it.
- `unrecord + reset` to shelve it again.

I’ll quick want to wrap that into scripts, though, with some sanity checks to avoid shooting myself in the foot. Which suggests it should be available built-in!

> [@pmeunier](#):
>
> pijul push . --to-channel debugging

Oh, nice. The help shows `"push Pushes changes to a remote upstream"` so I didn’t think it could help locally.

> [@pmeunier](#):
>
> One major use case for Pijul was my use of nixpkgs […]

Haha, funny to know. Well used, frustration is a powerful motivator!

---

<div class="post-metadata">

**Author:** ![pmeunier](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/pmeunier/32/4_2.png) [@pmeunier](https://discourse.pijul.org/u/pmeunier)\
**Post date:** [February 21, 2021, 5:30pm UTC](https://discourse.pijul.org/t/surprising-behaviours/736/9 "2021-02-21T17:30:33Z")

</div>

> [@unidual](#):
>
> `record + unrecord + diff > ~/.patch/ouli + reset` to create such a patch and shelve it.

There’s a simpler variant: `pijul diff > ~/.patch/ouli + reset`.

> [@unidual](#):
>
> `unrecord + reset` to shelve it again.

`pijul unrecord --reset` already exists.

---

<div class="post-metadata">

**Author:** ![pmeunier](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/pmeunier/32/4_2.png) [@pmeunier](https://discourse.pijul.org/u/pmeunier)\
**Post date:** [February 21, 2021, 5:31pm UTC](https://discourse.pijul.org/t/surprising-behaviours/736/10 "2021-02-21T17:31:38Z")

</div>

Note that `pijul unrecord --reset` commutes with other changes you have in the working copy: for example, you can unrecord and reset an old patch, while keeping your current work in the working copy (no need to record).

---

<div class="post-metadata">

**Author:** ![unidual](https://avatars.discourse-cdn.com/v4/letter/u/91b2a8/32.png) [@unidual](https://discourse.pijul.org/u/unidual)\
**Post date:** [February 21, 2021, 5:46pm UTC](https://discourse.pijul.org/t/surprising-behaviours/736/11 "2021-02-21T17:46:07Z")

</div>

> [@pmeunier](#):
>
> There’s a simpler variant: `pijul diff > ~/.patch/ouli + reset` .

I was thinking about creating a patch with a message. But I forgot that [`unrecord` discard the message anyway](https://nest.pijul.com/pijul/pijul/discussions/343).

> [@pmeunier](#):
>
> (no need to record)

Sweet!

---

<div class="post-metadata">

**Author:** ![pmeunier](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/pmeunier/32/4_2.png) [@pmeunier](https://discourse.pijul.org/u/pmeunier)\
**Post date:** [February 21, 2021, 5:54pm UTC](https://discourse.pijul.org/t/surprising-behaviours/736/12 "2021-02-21T17:54:29Z")

</div>

What would you think about `pijul diff -m "here is my message"`?

---

<div class="post-metadata">

**Author:** ![unidual](https://avatars.discourse-cdn.com/v4/letter/u/91b2a8/32.png) [@unidual](https://discourse.pijul.org/u/unidual)\
**Post date:** [February 21, 2021, 6:20pm UTC](https://discourse.pijul.org/t/surprising-behaviours/736/13 "2021-02-21T18:20:54Z")

</div>

Perfect! So much simpler.