feat: make regeneration not override nodes by default

[transmissions11]

can add a new keybind to do overriding

https://twitter.com/spring_stream/status/1640824513213652992?s=20

[jjranalli]

Correct me if wrong but if changing the prompt of a node in the middle of a tree creates new children nodes, once regeneration occurs the history / lineage of the previous ones is not going to be accurate anymore (also related to #7). This could lead to confusion or incorrect assumptions.

Note that this is already the case for:

• nodes further down the tree, when a regeneration with override happens
• more in general, children nodes of a node whose prompt has been edited (regardless of regeneration)

So thinking it might be desirable to:

• highlight "outdated" nodes in the UI, by storing lineageAtGeneration and detecting when it differs from current lineage
• highlight "edited" nodes, and exposing a command to revert to their original state
• add a command and shortcut to regenerate all outdated nodes

---

And going back to the issue at hand, if we don't want to partially invalidate the tree while regenerating without overriding, the ideal solution should be

• if prompt hasn't been edited
  1. Generate more nodes, instead of overriding
• if prompt has been edited
  1. Create a new sibling node with the edited prompt
  2. Trigger generation from that node

[transmissions11]

Correct me if wrong but if changing the prompt of a node in the middle of a tree creates new children nodes, once regeneration occurs the history / lineage of the previous ones is not going to be accurate anymore

yup this is definitely the case, but i'd consider this more of a design choice than a bug or something to be addressed with a lot of complexity. flux is a power tool for power users. there are valid cases where you might want to retroactively edit and prune the tree, even if that means the tree as it stands is not reproducible/deterministic. we provide people with all the tools to do things like this and make adjacent nodes for branching, overriding, etc if that's the behavior they want.

so in terms of this:

if we don't want to partially invalidate the tree while regenerating without overriding, the ideal solution should be
if prompt hasn't been edited
Generate more nodes, instead of overriding
if prompt has been edited
Create a new sibling node with the edited prompt
Trigger generation from that node

i do think this is one path we could go, but personally i think we should make this a path users can take if they want (by creating a new sibling node themselves with the new prompt, etc) but not force it upon them.

willing to reconsider down the line, but this is my take rn

[jjranalli]

Yes I agree. It definitely feels secondary, so not worth the increase in complexity and edge cases to handle this would come with.