-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maintain correct source order even when receiving new chapters from a sync service #1360
Conversation
app/src/main/java/eu/kanade/tachiyomi/data/backup/restore/restorers/MangaRestorer.kt
Outdated
Show resolved
Hide resolved
It was a lint error, you can run the automatic formatter by doing |
Thank you! I will keep that in mind in the future.
|
I always forget if it needs the |
… sync service (jobobby04/TachiyomiSY#1360) * Maintain correct source order even when receiving new chapters from sync service * Add comma required by build service (cherry picked from commit a32c7186e43fe616c5956f04c0cef50b450d97c1)
Just in case someone stumbles upon this for unrelated reasons, I am now using the following git pre-commit hook, which shoud work on both Windows and Linus and should make sure no commits get made in an invalid state: #!/bin/bash
echo "Running pre-commit hook (./gradlew spotlessApply)."
# Navigate to the repository root directory temporarily.
REPO_ROOT=$(git rev-parse --show-toplevel)
pushd "$REPO_ROOT" >/dev/null || {
echo "Failed to change directory to repository root. Aborting pre-commit hook."
exit 1
}
# Capture the output of the Gradle spotlessApply task.
OUTPUT=$(./gradlew spotlessApply 2>&1)
EXIT_CODE=$?
# Stage all changes made by spotlessApply.
git add -u
# Restore the original directory
popd >/dev/null
if [ $EXIT_CODE -ne 0 ]; then
echo "spotlessApply failed. Aborting commit."
echo "$OUTPUT"
exit $EXIT_CODE
fi
echo "spotlessApply completed successfully. Proceeding with commit." |
Fixes #1339
Problem description and origin
If chapters are pushed to a sync service from Device A and these new chapters are then received by Device B, the source order of these chapters will be wrong because the existing chapters have not gotten their source order adjusted. This source order usually changes when new chapters get added or old ones get removed, however, as-is local chapters will still be in the order of before with the new chapters now colliding with the old chapters (leading to orders like "Chapter 38" -> "Chapter 43" -> "Chapter 37" -> "Chapter 42" -> ...).
How this PR fixes the problem
The proposed changes now ensure that this corner case for syncing is caught and the
sourceOrder
of the chapters are now in the correct order. I made it so that existing behavior not sync-related should remain unaffected.Screenshot illustrating the problem