Chad ElliottandClaude Opus 5.5 5b8b9b521d fix(lightroom): a content duplicate keeps the metadata its file carries (#2589) ...

A catalog photo whose bytes match another library photo became a new record that took only the
camera description from that photo's record, so the copyright, rights, creator and other metadata
its file carries (EXIF, IPTC, embedded XMP), which a file import keeps, was lost whenever the
catalog's XMP didn't restate it. Copying them from the other record would have carried that
photo's edits instead.

The file import already reads each content duplicate before it skips it; the probed metadata now
rides on the duplicate (`Duplicate::file_meta`, not serialised) and the new record starts from it,
before the import defaults and the catalog's metadata go on top, as for a file import. Without a
probe (a path match, which this branch never sees) it keeps the exposure description only, no
longer the user-editable GPS.

Test: a content duplicate of a trashed photo, imported through the Lightroom job with a file
carrying copyright, status, usage terms and creator, keeps them and takes nothing from the other
record's edited notice, creator or GPS.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-29 23:56:50 -05:00

..

examples

refactor(bench): dispatch specialized render modes

2026-10-28 03:24:18 +00:00

src

fix(lightroom): a content duplicate keeps the metadata its file carries (#2589)

2026-10-29 23:56:50 -05:00

tests/it

CI: one test binary per crate, line tables only, one WASM check (#2710)

2026-10-23 13:34:30 -04:00

build.rs

fonts: Georgian UI text from craft-fonts' Noto Sans Georgian on the web

2026-10-18 16:14:56 +04:00

Cargo.toml

chore(deps): refresh safe dependency bumps (#2994)

2026-10-25 19:30:51 -04:00