git based hip file management

[johnnyquest]

hip save: new commit

what is it good for?

• merging, diffing
• shared hip files! cloning, work in parallel, pull / merge / push
• diffs: nodes created, edited, deleted, expressions changed, etc
• combine/split commits (git ui)
  downsides:
• merge conflict resolution will probably suck, big time...
• an easy way of handling conflicts must be worked out.

implementation order:

• first: save+commit (save hip, hexpand, commit)
  notes:
  • git repo is within the expanded folder structure
    • make sure not to delete it
    • create repo if doesn't exist
  • ask for a one-line commit text
  • next level shit: expand/commit in background
• second: check out and load current (reset/hard at current, build hip, load)
• test the above, see what's next

misc:

a tool that turns a .hip file and its backups into a git repository

• should be able to work incrementally (i.e. append to an existing repository)
• there should be a way provided to somehow pass commit messages

[bxyldy]

This is an incredible idea.
It might be cool to add some ROP gallery items that commit when executed, maybe with tagged with the type of ROP, and the output path as the commit message... or something. I'm getting carried away. But I can imagine that being incredibly useful for asset tracking.

[johnnyquest]

Glad you like it. I was thinking about not just asset tracking, but scene branching (e.g. storing different variants of a vfx in separate branches), diffing/cherrypicking/merging... if this worked in a practically usable way, that would be awesome.

But yeah, asset tracking would be another major thing. By the way, we did track our own qLib assets in ascii for quite some time (and it's very useful, as you can read all the changes in a diff window).

We switched to binary to get rid of a "compilation" phase of qLib (so right now you can just download/pull and all is ready to use without any preparation or pre-processing). We still have the python (and shell) utility scripts for converting any asset between binary/ascii.

[larsbijl]

just did a quick test on this.

• modification times for nodes changes so some nodes will show to be different when nothing changed.
• inputs sometimes changed without reason:

inputsNamed3
{
49  "" "" 1 "input1"
50  "" "" 1 "input2"
51  "" "" 1 "input3"
52  "" "" 1 "input4"
}

can become

inputsNamed3
{
}

• .userdata of a node is binary and can't be merged.
• .OPfallbacks and .OPpreferences are unorded list so will be a different order between commits.

[johnnyquest]

hm... maybe certain files could be preprocessed before doing the commit (e.g. sorting the unordered lists). i'm not a big fan of these kinds of "solutions", though :/ as of binary files, well, yeah, there's no merging those (except the "take the one from one of the branches" strategy -- I don't recall the name now).

i haven't yet given up the idea itself, i just don't have time for testing right now.

[johnnyquest]

• hmmm, probably not worth it
• bin/text conversions shuffle stuff around and add/change stuff that makes diffing a nightmare

closing this :/