An implementation of git fast-export for Pijul

#4 Strange renames

Closed on April 18, 2023
andybalholm on April 18, 2023

(This would seem to be a bug in libpijul or pijul git, rather than in pijul-export. But I’m opening it here so that I can easily attach the relevant code.)

In preparation for doing incremental exports instead of full-tree exports, I’ve started sending delete and rename commands to Git, not just modify commands. But in repositories created by pijul git, there are sometimes renames of files that don’t exist. For example, when I export https://nest.pijul.com/andybalholm/redwood/changes/NDKRFDQRH4CG6KBPIZRUTYH6ULZ5CFHDH55ZPKVXBFUCXOOS2ZLAC, the list of file changes looks like this:

R "log.go" "73IDY562P4SGLHF3CLOA5JUO6UAWN5C7ZVBM5J3USQQ7DZ4KF75Q"
R "iprange.go" "R73KRFGQQV5D3DUVE5M3RU7CJM4HUWFKZTJI55AJ5QFZSZ5PUCPQ"
M 644 :1000000001 "webserver.go"
M 644 :1000000002 "testmode.go"
M 644 :1000000003 "phrase_scan.go"
M 644 :1000000004 "jslexer.go"
M 644 :1000000005 "redwood.go"
M 644 :1000000006 "phrase.go"
M 644 :1000000007 "blockpage.go"
M 644 :1000000008 "73IDY562P4SGLHF3CLOA5JUO6UAWN5C7ZVBM5J3USQQ7DZ4KF75Q"
M 644 :1000000009 "LICENSE"
M 644 :1000000010 "reqmod.go"
M 644 :1000000011 "queries.go"
M 644 :1000000012 "context.go"
M 644 :1000000013 "spec.tex"
M 644 :1000000014 "mime.go"
M 644 :1000000015 "mapsort.go"
M 644 :1000000016 "respmod.go"
M 644 :1000000017 "prune.go"
M 644 :1000000018 "R73KRFGQQV5D3DUVE5M3RU7CJM4HUWFKZTJI55AJ5QFZSZ5PUCPQ"
M 644 :1000000019 "rule.go"
M 644 :1000000020 "config.go"
M 644 :1000000021 "charset.go"
M 644 :1000000022 "categories.go"
M 644 :1000000023 ".hgignore"
M 644 :1000000024 "word.go"
M 644 :1000000025 "url.go"
R "73IDY562P4SGLHF3CLOA5JUO6UAWN5C7ZVBM5J3USQQ7DZ4KF75Q" "accesslog.go"
R "R73KRFGQQV5D3DUVE5M3RU7CJM4HUWFKZTJI55AJ5QFZSZ5PUCPQ" "filtergroups.go"

(The lines starting with M are filemodify commands, setting a file’s contents, and the lines starting with R are filerename commands.)

andybalholm added a change on April 18, 2023
T3IX7GG7BIFN3AX3QQWRPS5CKFZVRU5TRQAMJSYN4FEJXQL75PJQC
main
andybalholm on April 18, 2023

This is somehow a result of starting with a Git repository with two initial commits (i.e., two commits that don’t have a parent). So although it would be nice to understand what’s going on and do something a little more sensible in a case like this, it’s basically a case of GIGO.

andybalholm closed this discussion on April 18, 2023