From 1ee857c18a0082f89998eccef878c32b1de332ef Mon Sep 17 00:00:00 2001
From: Adrien Tiburce <34744867+adrientiburce@users.noreply.github.com>
Date: Sat, 13 Apr 2024 02:44:28 +0200
Subject: [PATCH 1/2] fix: migration repair example more understandable

---
 docs/supabase/migration/repair.md | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/docs/supabase/migration/repair.md b/docs/supabase/migration/repair.md
index f6e7dd3b9..2e300d787 100644
--- a/docs/supabase/migration/repair.md
+++ b/docs/supabase/migration/repair.md
@@ -12,13 +12,14 @@ For example, your migration history table may look like this after running `db p
 $ supabase migration list
         LOCAL      │     REMOTE     │     TIME (UTC)
   ─────────────────┼────────────────┼──────────────────────
-    20230103054303 │ 20230103054303 │ 2023-01-03 05:43:03
+                   │ 20230103054303 │ 2023-01-03 05:43:03
+   20230103054315  │                │ 2023-01-03 05:43:15
 ```
 
 To reset your migration history to a clean state, first delete your local migration file.
 
 ```bash
-$ rm supabase/migrations/20230103054303_remote_commit.sql
+$ rm supabase/migrations/20230103054315_remote_commit.sql
 $ supabase migration list
         LOCAL      │     REMOTE     │     TIME (UTC)
   ─────────────────┼────────────────┼──────────────────────

From 86461a8c69057b7b0eb0d03c2f970f3a81a3570c Mon Sep 17 00:00:00 2001
From: Han Qiao <sweatybridge@gmail.com>
Date: Sun, 14 Apr 2024 12:51:54 +0800
Subject: [PATCH 2/2] Update repair.md

---
 docs/supabase/migration/repair.md | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/docs/supabase/migration/repair.md b/docs/supabase/migration/repair.md
index 2e300d787..981bb9cb8 100644
--- a/docs/supabase/migration/repair.md
+++ b/docs/supabase/migration/repair.md
@@ -6,7 +6,7 @@ Requires your local project to be linked to a remote database by running `supaba
 
 If your local and remote migration history goes out of sync, you can repair the remote history by marking specific migrations as `--status applied` or `--status reverted`. Marking as `reverted` will delete an existing record from the migration history table while marking as `applied` will insert a new record.
 
-For example, your migration history table may look like this after running `db pull` for the first time.
+For example, your migration history may look like the table below, with missing entries in either local or remote.
 
 ```bash
 $ supabase migration list
@@ -20,6 +20,7 @@ To reset your migration history to a clean state, first delete your local migrat
 
 ```bash
 $ rm supabase/migrations/20230103054315_remote_commit.sql
+
 $ supabase migration list
         LOCAL      │     REMOTE     │     TIME (UTC)
   ─────────────────┼────────────────┼──────────────────────
@@ -30,10 +31,27 @@ Then mark the remote migration `20230103054303` as reverted.
 
 ```bash
 $ supabase migration repair 20230103054303 --status reverted
-Repaired migration history: 20230103054303 => reverted
+Connecting to remote database...
+Repaired migration history: [20220810154537] => reverted
+Finished supabase migration repair.
+
 $ supabase migration list
         LOCAL      │     REMOTE     │     TIME (UTC)
   ─────────────────┼────────────────┼──────────────────────
 ```
 
 Now you can run `db pull` again to dump the remote schema as a local migration file.
+
+```bash
+$ supabase db pull
+Connecting to remote database...
+Schema written to supabase/migrations/20240414044403_remote_schema.sql
+Update remote migration history table? [Y/n]
+Repaired migration history: [20240414044403] => applied
+Finished supabase db pull.
+
+$ supabase migration list
+        LOCAL      │     REMOTE     │     TIME (UTC)
+  ─────────────────┼────────────────┼──────────────────────
+    20240414044403 │ 20240414044403 │ 2024-04-14 04:44:03
+```