Reset auto-applied presets flag and edit timestamp when restoring a snapshot with empty history

[jeffc]

This fixes a bug I encountered when I do the following steps:

1. Edit image A
2. Copy image A's history stack (full or partial) and paste onto image B, which was previously unedited
3. Undo that paste operation

Before this change, if I opened image B for editing, none of the my automatically-applied presets would be applied. This change resets the "auto-apply presets" flag and the edit timestamp when undoing the last remaining change in the history stack. This properly resets image B to an "unedited" state, and it properly gets presets applied when it's opened for editing.

[TurboGit]

B must have been just imported without having touched before, right?

[jeffc]

It can't have been edited at all, but it can have ratings/labels assigned.

I noticed this bug in the course of my normal workflow:

First, I Import all the pictures from a shoot. Next, I cull down to the ones I want to edit (I use color labels for this) and tag. After that, I tend to just edit in order.

If I have a series of shots in basically identical lighting conditions with identical settings, I'll often want to do the basic exposure/color correction on the first one and then copy/paste that on to the rest in the series before doing final edits individually. Sometimes this works great, but other times I can tell from the lighttable previews that the edits from the first image don't work well on the others, so I'll hit undo. I noticed that when I did that and then went to any of the images that had gotten that paste/undo, they no longer had presets auto-applied.

[TurboGit]

Thanks!

[TurboGit]

The patch seems correct but I'm wondering if it would be better to store the actual change status into the undo record and always reset it to previous status when doing undo/redo. I suppose this is cleaner as using the actual undo/redo support and will work in all cases without having to special case this status.

[jeffc]

The patch seems correct but I'm wondering if it would be better to store the actual change status into the undo record and always reset it to previous status when doing undo/redo. I suppose this is cleaner as using the actual undo/redo support and will work in all cases without having to special case this status.

I was trying to make the smallest possible change that I could and still fix the problem, and this was the best I could do. If you think that's a better answer I can take a swing at it!

[TurboGit]

Yes I think it is worth looking for adding the change status into the undo/redo record. Let me know if you need pointers. TIA.