4 ms·
> lore stage covers adds, edits, and deletes — you use the same command for all three. Stage a deleted file and Lore records the deletion for the next commit. M
by ibejoeb 4mo ago
> lore stage covers adds, edits, and deletes — you use the same command for all three. Stage a deleted file and Lore records the deletion for the next commit. Moves and renames are tracked too, through a dedicated subcommand: lore stage move <from> <to> records the rename so the file keeps its identity and history across the move instead of registering as a delete plus an add.
Oof. So this isn't compatible with any tools that move or rename files. I can't see how this will be acceptable for real-world use.
- xboxnolifes 4mo agoIsn't this just the same thing as `git mv`?
- ibejoeb 4mo agoI don't think so, but I'm not sure. It seems to imply that renaming a file without using `lore stage` subcommands will record a delete and an add, meaning that changes made in a branch prior to the rename won't automatically propagate. Git will detect this without using it's own mv command.
- IshKebab 4mo agoNo they're saying that it will explicitly record the move, unlike Git which has to guess (it often fails).
- IshKebab 4mo agoThey're actually saying it's better than `git mv`, because it actually records the move, unlike Git.
- ibejoeb 4mo agoI think they're saying the opposite. It won't detect a filesystem-level move. It will simply record a delete and create without the relationship. Git does record the rename, though: ~/work/tmp/repo git init . --quiet ~/work/tmp/repo master echo 'foo' > foo.txt ~/work/tmp/repo master? git add . ~/work/tmp/repo master+ git commit -m "create" --quiet ~/work/tmp/repo master mv foo.txt bar.txt # no `git mv` ~/work/tmp/repo master*? git add . ~/work/tmp/repo master+ git status --porcelain R foo.txt -> bar.txt ~/work/tmp/repo master+ git commit -m "rename" [master a06c680] rename 1 file changed, 0 insertions(+), 0 deletions(-) rename foo.txt => bar.txt (100%) Git knows that the file was renamed even without using git to do the rename. This means that it doesn't matter if you IDE, codemod, agent, or whatever does it. Git tracks that foo.txt and bar.txt refer to the same blob at different revisions. Maybe lore does the same, but the docs imply that it doesn't. -- To summarize: lore will record relationship metadata only when performed with `lore stage move <from> <to>`, so you will have to intervene if your other tooling moves files.
- IshKebab 4mo ago> Git knows that the file was renamed even without using git to do the rename. No it doesn't. Git knows that file A was deleted and file B was created, and if they have the same content then it will guess that it was a rename. But it's a heuristic that doesn't always work. E.g. I think it doesn't try to guess for large diffs, and it doesn't work if you modify the file in the same commit.
- ibejoeb 4mo agoRight, if you rename a file and then change its content without committing it, it doesn't know. Clearly that's bad practice in a multi-user setting because you're going to break all subsequent merges. However, if you just move or rename a file, git does recognize that, and it doesn't require any manually annotation. Lore needs you to tell it that you're moving or renaming. It's not the end of the world, but it's a real pain if other tools are operating on the file. You will need to go back and manually annotate those operations if you want it to preserve the relationships.