# What's the behaviour when pushing changes with should\_cache = true?

**URL:** <https://discourse.pijul.org/t/whats-the-behaviour-when-pushing-changes-with-should-cache-true/1066>\
**Category:** Question\
**Created:** [July 3, 2023, 11:57am UTC](https://discourse.pijul.org/t/whats-the-behaviour-when-pushing-changes-with-should-cache-true/1066 "2023-07-03T11:57:00Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![PackmanDude](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/packmandude/32/524_2.png) [@PackmanDude](https://discourse.pijul.org/u/PackmanDude)\
**Post date:** [July 3, 2023, 11:57am UTC](https://discourse.pijul.org/t/whats-the-behaviour-when-pushing-changes-with-should-cache-true/1066/1 "2023-07-03T11:57:00Z")

</div>

I’m always accidentally closing the first window that pops up my default text editor, when using  
`pijul push -f`

Which help page states:

> Force an update of the local(,) remote cache.

At some circumstances it’s possible to get first: opened file that my question is about, and second: file with list of changes to push to the remote. Is it something important? Because, I can’t get it to show again.

---

<div class="post-metadata">

**Author:** ![PackmanDude](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.pijul.org/packmandude/32/524_2.png) [@PackmanDude](https://discourse.pijul.org/u/PackmanDude)\
**Post date:** [July 8, 2023, 10:11pm UTC](https://discourse.pijul.org/t/whats-the-behaviour-when-pushing-changes-with-should-cache-true/1066/2 "2023-07-08T22:11:46Z")

</div>

Okay, to close this:

The answer was “The following changes are new in the remote (and are not yet known to your local copy)” is what’s told in a first window when doing “unspecified” action (unspecified by me until now).  
Now, I know why it triggers, when you want to unrecord something and replace with new changes and then push, it will occur.

It’s nowhere explained, but for anyone unfamiliar: it exists for you to unrecord changes on the remote, so then it can lie on the repo state (a bunch of patches) nicely. If not, it just copies over. So, `push -f` indeed does what’s specified (or at least it does not do what’s unspecified) and it is not intended to be used as `git reset --hard` + `git push -f` to override repo’s history. Just like `pijul unrecord` is not like `git reset`, it _unrecords_ change, not jumps to it.  
Pijul does what it says it does. I think that’s important for newcomers to realise if they are migrating from other VCS.