mirror of
https://github.com/martinvonz/jj.git
synced 2025-05-05 15:32:49 +00:00
33a5d21e3a
The property-based test exposed another bug; this can be reproduced in
the following way:
$ touch empty-file
$ jj commit -m "add non-executable file"
$ jj split
...then select the file mode change interactively and give the split-off
change a name. Since all the changes have been selected, one would
expect the first part to contain the file mode change and the second
part to be empty, but in fact:
First part: nrkmknyr 785bfe6e (empty) bla
Second part: qmwwknqx b5a92967 (no description set)
Doing the equivalent thing non-interactively has the expected result:
$ jj undo
$ jj split empty-file
Warning: All changes have been selected, so the second commit will be empty
First part: nrkmknyr 3f156f9e first
Second part: zlurmpxm 06e24b2d (empty) (no description set)
This problem only occurs when the file is empty.
When the file mode of an empty text file changes, scm-record produces
`SelectedContents::Unchanged`, even though there is a change that
needs to be addressed. AFAICT, empty files are the only situation
where `Unchanged` is produced. If the file mode of a non-empty file
is changed, `SelectedContent::Text` is produced, even though the file
itself has not changed and does not have to be written to the store.
With the current semantics, IMHO `Unchanged` is a little misleading and
acts more like an `Empty`.
Knowing this, it is possible to fix the bug by just writing an empty
file. However, this is a little wasteful to have to write the file blob
anew when it hasn't changed (both when the file is empty or not). It
would be nicer to have scm-record report an actual `Unchanged` (also
when a non-empty file hasn't changed) and to have some way to update the
executable flag in `MergedTreeBuilder` rather then having to provide a
new value from scratch.