[Compress History] Does not compress on a duplicate file

[chhil]

Describe the bug Edited an image. Created a virgin duplicate, history of dup has the default 0-8 steps. Added 3d lut to virgin dup. Double click or single click step 0:Original in history. Clicked compress history stack. Did not compress history as lut3d module still in history, expected the default 0-8 steps but there was 0-9 steps with step 9 in history for lut3d.

However, if I click on any other step other than original and compress history it works fine.

Platform (please complete the following information):

• OS: Win 10
• Version [e.g. 2.7.0.2054]

[jenshannoschwalm]

@Turbogit this is not only un duplicates. Should a "compress history" on original discard the history? If you concider this a bug - i personally really dont't care - i would do a pr for this. Otherwise nothing to worry about.

[parafin]

This is most definitely a bug, I would expect that compressing on any of 0-8 steps should result in the default 0-8 steps (maybe in different order, because it doesn't matter).

[TurboGit]

I agree too. This is a bug to me. Not very bad one, but still a bug. @jenshannoschwalm : yes please create a pr for that, thanks a lot in advance!

[chhil]

@jenshannoschwalm , just want to make sure this fix is for both compression of history on individual images and on duplicate images.

Also the history does get compressed when its a step other than 0, so does adding a specific check for 0 makes sense? What I mean is that the logic to compress is already out there, just that it was not honoring the extreme condition.

if (my_history_end == 0) { dt_history_delete_on_image(imgid); return; }

[TurboGit]

Also the history does get compressed when its a step other than 0, so does adding a specific check for 0 makes sense?

Yes because 0 is a special case meaning nothing has been done on the image yet and there is no such entry in the db.

[TurboGit]

And yes it works for duplicate as there is just no difference at the level of handling in the code.