i need to figure out how to run this project...and do some demo examples..i need you to make me some kind of tutorial · Entire

Home

Log in

i need to figure out how to run this project...and do some demo examples..i need you to make me some kind of tutorial

2mo ago·4.1s·51 calls

I’ll map the repo first so the tutorial is grounded in what this project actually does, then I’ll write it into the workspace in a useful format rather than hand-wave from the README.

I’ve got a Go repo with two commands (git-sync and git-sync-bench) plus a library API. Next I’m reading the existing docs and runnable entry points so the tutorial can cover both “try it quickly” and “understand what happened.”

One wrinkle: go isn’t on this shell’s PATH, but the repo has mise.toml, so I’m checking the project’s tool setup next. That matters for the tutorial because “run this” should work on this machine from a clean shell.

mise is present and is pulling the configured Go toolchain/tooling now. I’m going to verify the actual run commands and, if the local Git HTTP backend is available, include a demo that uses only disposable local repos.

The benchmark command can exercise a local file:// target directly, while the main CLI’s realistic demo path is smart HTTP. I’m checking both so the tutorial can give you the shortest possible demo and the closer-to-production one.

I’m going to add a small tutorial plus a local demo script. The script will create disposable source/target repos, serve them through Git’s smart HTTP backend, run plan, sync, branch mapping, and an incremental update, then show the resulting refs.

The tutorial and demo script are in place. I’m running the demo now, because runnable documentation that hasn’t met a terminal yet is still a little too theoretical for my taste.

The first local demo exposed a real macOS/CGI edge case: chunked request bodies are rejected by git http-backend when run through CGI. I’m tightening the tiny demo server so it buffers request bodies and sets Content-Length, which keeps the demo simple and still exercises real smart HTTP.

The demo now completes cleanly and shows the expected main and stable target refs. I’m doing one last pass over the added files and a lightweight syntax check.

Done. I added:

I verified it with:

1
2
3
4

bash docs/demo-local-smart-http.sh
bash -n docs/demo-local-smart-http.sh
mise exec -- shellcheck docs/demo-local-smart-http.sh
mise exec -- go test ./cmd/git-sync ./cmd/git-sync-bench

Run the tutorial demo with:

1
2

cd /Users/rizel/Documents/work/gitsync
bash docs/demo-local-smart-http.sh

do i need a demo repo or something to try this out on

2mo ago·6.6s

No, you don’t need to create one manually.

I added a demo script that creates temporary demo repos for you:

1
2

cd /Users/rizel/Documents/work/gitsync
bash docs/demo-local-smart-http.sh

It automatically creates:

By default it cleans everything up when done.

If you want to keep the demo repos and poke around afterward:

1

GITSYNC_DEMO_ROOT=/tmp/gitsync-demo bash docs/demo-local-smart-http.sh

Then inspect them:

1
2
3

git --git-dir=/tmp/gitsync-demo/source.git show-ref
git --git-dir=/tmp/gitsync-demo/target.git show-ref
git --git-dir=/tmp/gitsync-demo/target.git log --oneline --all --decorate

what parts of this would be cool to screen record or screenshot to show the value of git sync

2mo ago·9.4s

Yes. For a good demo recording, I’d show the value as: “no local clone, preview first, sync safely, rerun incrementally.”

A strong screen-record flow:

  1. Start With The Problem Show the two empty/demo repos:
1
2

git --git-dir=/tmp/gitsync-demo/source.git show-ref
git --git-dir=/tmp/gitsync-demo/target.git show-ref

Point: target starts empty.

  1. Preview Before Changing Anything Run:
1

./git-sync plan --branch main --json <source-url> <target-url>

Screenshot the JSON plans section showing:

This is a great “automation-friendly and safe” moment.

  1. Initial Sync Run:
1

./git-sync sync --branch main --json <source-url> <target-url>

Screenshot:

This shows the big value: it bootstraps the empty target through relay.

  1. Verify Target Got The Ref Run:
1

git --git-dir=/tmp/gitsync-demo/target.git show-ref

Screenshot refs/heads/main appearing on the target.

  1. Incremental Sync Add a second commit to source, push it, then run:
1

./git-sync sync --branch main --stats --json <source-url> <target-url>

Screenshot:

This is probably the best value shot: reruns only move the delta, with stats.

  1. Branch Mapping Run:
1

./git-sync sync --map main:stable --json <source-url> <target-url>

Screenshot:

This shows it’s not just “copy everything blindly”; it has controlled ref mapping.

Best single screenshot: the JSON from incremental sync showing relay: true, relayMode: "incremental", pushed: 1, and stats.

Best short recording: run this and narrate as it goes:

1

GITSYNC_DEMO_ROOT=/tmp/gitsync-demo bash docs/demo-local-smart-http.sh

Then zoom in on the JSON chunks for plan, bootstrap, and incremental.

how long do you think the video will be

2mo ago·4.7s

I’d aim for 2 to 3 minutes.

A good pacing:

If you want it tighter for social/Slack, you could make a 60-90 second version focused only on: plan, sync, incremental sync.

what about a screnshot..yeah i was looking for like 30 - 60 seconds of certain things

2mo ago·6.4s

Yeah, for 30-60 seconds, I’d make it a tight “3 proof points” clip or screenshots carousel.

Best 30-60 sec recording

  1. Preview Run plan --json. Highlight:
1
2

"action": "create",
"dryRun": true

Message: “Preview exact ref changes before pushing.”

  1. Bootstrap Sync Run sync --json. Highlight:
1
2
3

"pushed": 1,
"relay": true,
"relayMode": "bootstrap"

Message: “Seed an empty target through relay.”

  1. Incremental Sync After second commit, run sync --stats --json. Highlight:
1
2
3

"action": "update",
"relayMode": "incremental",
"stats": { "enabled": true }

Message: “Reruns move only the update path and emit machine-readable stats.”

Best screenshots

Screenshot 1: plan --json Capture the plans block with sourceRef, targetRef, action, reason, and dryRun.

Screenshot 2: first sync --json Capture pushed: 1, relay: true, relayMode: "bootstrap".

Screenshot 3: incremental sync --stats --json Capture action: "update", relayMode: "incremental", and a bit of the stats.items block.

Screenshot 4, optional: final refs

1

git --git-dir=/tmp/gitsync-demo/target.git show-ref

Show:

... refs/heads/main
... refs/heads/stable

For a single hero screenshot, use the incremental sync JSON. It shows the most value at once: safe planning, actual update, relay mode, and stats.

okay there's a little drama around people wanting to get off of github cuz github has been so unreliable lately so i was thinking of doing a tweet thread of the Entire account that says this

For anyone suddenly feeling the urge to move their project somewhere new, we’re open sourcing our latest project, git-sync, today.

git-sync mirrors refs from an source remote to a target remote without a local checkout, streaming packfiles directly over smart HTTP with an in-memory object store.

A step forward as we build an agent-native git layer where code and agent activity move, sync, and evolve across systems continuously.

< picture>

2mo ago·9.5s

Yes. The framing is strong, but I’d soften the GitHub drama slightly so Entire sounds opportunistic in the good way, not dunking. Also fix “from an source” to “from a source.”

Here’s a tighter version:

For anyone suddenly feeling the urge to move their project somewhere new:

We’re open sourcing git-sync today.

git-sync mirrors refs from a source remote to a target remote without a local checkout, streaming packfiles directly over smart HTTP with an in-memory object store.

It’s a step toward the agent-native git layer we’re building at Entire: one where code and agent activity can move, sync, and evolve across systems continuously.

<image>
<link>

For a thread, I’d do:

1/ For anyone suddenly feeling the urge to move their project somewhere new:

We’re open sourcing git-sync today.

<link>

2/ git-sync mirrors refs from a source remote to a target remote without a local checkout.

It streams packfiles directly over smart HTTP with an in-memory object store, so mirroring does not have to mean maintaining a local mirror clone.

3/ It supports previewable plans, branch mapping, tag mirroring, pruning, JSON output, stats, and safe fast-forward syncs.

Initial empty-target syncs use bootstrap relay; later fast-forward updates can use incremental relay.

4/ This is a step toward the agent-native git layer we’re building at Entire:

code and agent activity moving, syncing, and evolving across systems continuously.

5/ Try the local demo:

bash docs/demo-local-smart-http.sh

It spins up disposable source/target repos over smart HTTP and walks through plan, sync, incremental sync, and branch mapping.

Best image for the post: screenshot the JSON showing:

1
2
3

"pushed": 1,
"relay": true,
"relayMode": "incremental"

That’s the crispest “this is doing something real” moment.

well im already doing thi for the first part of the thread..like this is tweet 1

For anyone suddenly feeling the urge to move their project somewhere new, we’re open sourcing our latest project, git-sync, today.

A step forward as we build an agent-native git layer where code and agent activity move, sync, and evolve across systems continuously.

< picture>

2mo ago·5.3s

That works as tweet 1. I’d only make a few small edits for flow and grammar:

For anyone suddenly feeling the urge to move their project somewhere new, we’re open sourcing our latest project, git-sync, today.

It’s a step forward as we build an agent-native git layer where code and agent activity move, sync, and evolve across systems continuously.

< picture >
< link to repo >

Main fixes:

For the picture on tweet 1, I’d use a screenshot that shows either:

1
2
3

"relay": true,
"relayMode": "incremental",
"pushed": 1

or a terminal split showing:

git-sync plan --json
git-sync sync --json
refs/heads/main
refs/heads/stable

The first is more technical. The second is more immediately legible.

okay yeah yeah yeah..now we need tweet 2 and tweet 3..something that slightly leans into the controversy but really leans more on showing off how cool this is so pthat developers would want to try it out. here's an example

For the past few months, @pierrecomputer has been working on a brand new primitive, Trees. Just like Diffs, it’s an incredibly fast, modern, and beautiful library for rendering lists of files and folders. 2:26 PM · Apr 22, 2026 · 157.4K Views Relevant View quotes

Mark Otto

@mdo · Apr 22 When we say incredibly fast, it can render a fully interactive file tree for the entire Linux codebase (93,000 paths) in under 50ms. Here's a little taste of that, plus sticky headers, from our homepage demo. Amazing engineering from @SlexAxton and @amadeus for Trees & Diffs.

Mark Otto

@mdo · Apr 22 We built our own VS Code icon extension and then brought it back into Trees for custom file icons. We also added support for bringing in Shiki themes, just like our Diffs, so you can build matching components. Plus CSS variables, density options, and more. Mark Otto

@mdo · Apr 22 It's all at https://trees.software. Happy Earth Day, y'all—go plant, err, build some trees.

2mo ago·6.5s

Totally. For tweet 2 and 3, I’d make the controversy the door, then quickly move to “here’s the technical thing worth trying.”

Tweet 2

Most git migration tools assume you’ll make a local mirror clone, fetch everything down, then push it back up somewhere else.

git-sync takes a different path: it talks smart HTTP directly, plans every ref update first, and streams source packs into the target when it can.

Tweet 3

The cool bit: reruns are incremental.

If the target already has history, git-sync advertises target tips as `have`, fetches only what it needs from the source, and pushes explicit ref updates to the target.

No checkout. JSON output. Branch mapping. Stats. Built for automation.

A slightly spicier tweet 2:

When your git host has a bad day, “just clone it all locally and push it somewhere else” starts feeling a little less charming.

git-sync is our answer: previewable, scriptable remote-to-remote ref mirroring over smart HTTP, without turning migration into a local storage problem.

I’d use the spicier one if this is going out while the GitHub frustration is hot. Then tweet 3 can stay technical and grounded.

isnt your spicier tweet 2 just basically my tweet 1

2mo ago·32.7s

Yeah, you’re right. It’s doing the same job as tweet 1: “GitHub drama → here’s git-sync.” We don’t need to repeat that beat.

Tweet 2 should now show the mechanism. Tweet 3 should show the developer payoff.

Tweet 2

Under the hood, git-sync talks Git smart HTTP directly:

- reads source + target ref advertisements
- plans the exact ref updates before pushing
- fetches from source with target tips advertised as `have`
- streams the resulting pack into target `receive-pack`

No working tree required.

Tweet 3

That means you can use it for quick migrations, repeat sync jobs, and automation flows where the output needs to be inspectable.

Preview with `plan --json`, run with `sync --json`, map branches with `--map main:stable`, and collect transfer stats with `--stats`.

Or tighter / less bullet-y:

Tweet 2

The fun part is that git-sync talks Git smart HTTP directly.

It reads source + target refs, plans the update, fetches from source with target tips advertised as `have`, then streams the pack into target `receive-pack`.

No working tree required.

Tweet 3

So the workflow is simple:

preview with `plan --json`
sync with `sync --json`
map branches with `--map main:stable`
collect transfer stats with `--stats`

Useful for migrations, repeat sync jobs, and automation that needs inspectable output.

I’d pick the tighter versions. They feel more like a product thread and less like docs pasted into a timeline.

the other thing is i need them to match with 1 screenshot and 1 screen recording..so i kinda liked this but how would it match

Most git migration tools assume you’ll make a local mirror clone, fetch everything down, then push it back up somewhere else.

git-sync takes a different path: it talks smart HTTP directly, plans every ref update first, and streams source packs into the target when it can.

it can be more than 3 tweets..if needed..but like let's figure out

[nexttweet] simple video

[next tweet] simple screenshot

2mo ago·11.9s

Yeah, that tweet can match really well if we make the media do the proof.

I’d structure it as 4 tweets total:

Tweet 1: announcement Your current tweet, with the tiny grammar fix:

For anyone suddenly feeling the urge to move their project somewhere new, we’re open sourcing our latest project, git-sync, today.

A step forward as we build an agent-native git layer where code and agent activity move, sync, and evolve across systems continuously.

<repo link>

Tweet 2: concept + simple diagram/screenshot This is where your “most migration tools” framing fits.

Most git migration tools assume you’ll make a local mirror clone, fetch everything down, then push it back up somewhere else.

git-sync takes a different path: it talks smart HTTP directly, plans every ref update first, and streams source packs into the target when it can.

Media: screenshot/graphic showing:

source remote  ->  git-sync  ->  target remote
              smart HTTP / pack relay

no local checkout
no persistent mirror clone

Or a terminal screenshot of plan --json showing "dryRun": true and "action": "create".

Tweet 3: video demo Keep this tweet extremely simple because the video carries it.

Here’s the whole flow locally:

1. preview the ref update with `plan --json`
2. sync an empty target with bootstrap relay
3. add a commit
4. rerun with incremental relay + stats

No checkout. No local mirror repo.

Media: 30-60 second screen recording of docs/demo-local-smart-http.sh, zooming/cropping to the JSON moments:

Tweet 4: screenshot / developer payoff This is the “try it” tweet.

The output is built for automation: stable JSON plans, per-ref actions, relay mode, stats, and blocked/skipped/deleted counts.

You can preview with `plan`, run with `sync`, map branches with `--map main:stable`, mirror tags, prune refs, and wire it into migration jobs.

Media: screenshot of the incremental sync JSON showing:

1
2
3
4
5
6
7

"action": "update",
"pushed": 1,
"relay": true,
"relayMode": "incremental",
"stats": {
  "enabled": true
}

My recommendation:

If you only want one screenshot and one video, then use:

no it needs to be the terminal with git sync for any screenshots/graphics/screen recordings

2mo ago·10.9s

Yes, perfect. Then keep all media as terminal output, and make each tweet point to a specific terminal moment.

I’d do 4 tweets:

Tweet 1: Announcement Your current tweet + repo link. No media, or use the best terminal screenshot here if you want the first tweet to carry the image.

Tweet 2: Why It’s Different + Screenshot Text:

Most git migration tools assume you’ll make a local mirror clone, fetch everything down, then push it back up somewhere else.

git-sync takes a different path: it talks smart HTTP directly, plans every ref update first, and streams source packs into the target when it can.

Screenshot: terminal showing git-sync plan --branch main --json ...

Crop around:

1
2
3

"action": "create",
"reason": "create refs/heads/main...",
"dryRun": true

This screenshot proves “plans every ref update first.”

Tweet 3: Video Text:

Here’s the local demo flow:

`plan --json` previews the ref update
`sync --json` bootstraps an empty target
a second commit syncs through incremental relay
`--map main:stable` writes to a different target branch

No checkout. No local mirror clone.

Screen recording: 30-60 seconds of the demo script, but edit/crop to these terminal beats:

$ git-sync plan --branch main --json ...
"dryRun": true

$ git-sync sync --branch main --json ...
"pushed": 1
"relay": true
"relayMode": "bootstrap"

$ git-sync sync --branch main --stats --json ...
"relayMode": "incremental"
"stats": { "enabled": true }

$ git --git-dir=.../target.git show-ref
... refs/heads/main
... refs/heads/stable

Tweet 4: Developer Payoff + Screenshot Text:

The output is meant for automation: stable JSON, per-ref plans, relay mode, stats, and blocked/skipped/deleted counts.

So you can preview with `plan`, run with `sync`, map branches with `--map main:stable`, mirror tags, prune refs, and wire it into migration jobs.

Screenshot: terminal showing the incremental sync JSON. Crop around:

1
2
3
4
5
6
7

"action": "update",
"pushed": 1,
"relay": true,
"relayMode": "incremental",
"stats": {
  "enabled": true
}

If you only want one screenshot + one recording, I’d use:

Try it locally:

bash docs/demo-local-smart-http.sh

is there a deno scenario for plan

2mo ago·6.4s

Yes, there’s a clean demo scenario for plan:

Story: target repo is empty, source has main, and before syncing anything we preview exactly what git-sync would do.

Command:

1

git-sync plan --branch main --json <source-url> <target-url>

Best terminal screenshot crop:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

{
  "plans": [\
    {\
      "branch": "main",\
      "sourceRef": "refs/heads/main",\
      "targetRef": "refs/heads/main",\
      "kind": "branch",\
      "action": "create",\
      "reason": "create refs/heads/main at ..."\
    }\
  ],
  "pushed": 0,
  "dryRun": true
}

Tweet copy to match:

Before git-sync pushes anything, it can show the exact ref update plan.

Here the target is empty, so `plan --json` says it would create `refs/heads/main`, but `dryRun: true` means nothing has been written yet.

That is probably the best screenshot for “safe, inspectable migration.” It shows value without needing people to understand packfiles yet.

what would be my urls..i have everything on github

2mo ago·10.8s

Your URLs are just the HTTPS clone URLs for the GitHub repos:

1
2

https://github.com/<source-owner>/<source-repo>.git
https://github.com/<target-owner>/<target-repo>.git

Example shape:

1
2

SOURCE_URL="https://github.com/entire-dev/some-existing-repo.git"
TARGET_URL="https://github.com/entire-dev/git-sync-demo-target.git"

For a safe demo, create a brand new empty target repo on GitHub, like:

git-sync-demo-target

Then run:

1
2
3
4
5
6
7
8

export GITSYNC_SOURCE_TOKEN=...
export GITSYNC_TARGET_TOKEN=...

mise exec -- go run ./cmd/git-sync plan \
  --branch main \
  --json \
  "$SOURCE_URL" \
  "$TARGET_URL"

Then the actual sync:

1
2
3
4
5

mise exec -- go run ./cmd/git-sync sync \
  --branch main \
  --json \
  "$SOURCE_URL" \
  "$TARGET_URL"

If the source repo is public, you may not need GITSYNC_SOURCE_TOKEN, but you almost certainly need GITSYNC_TARGET_TOKEN because pushing to the target requires write access.

For screenshots, I’d use:

1
2
3
4
5

mise exec -- go run ./cmd/git-sync plan \
  --branch main \
  --json \
  https://github.com/YOUR_ORG/YOUR_SOURCE.git \
  https://github.com/YOUR_ORG/git-sync-demo-target.git

Just don’t point the target at any repo you care about for the demo. Make it empty and disposable.

i dont think i want to really put in a target url and source url..but i wish i could just have it be faked or something

2mo ago·8.5s·9 calls

Yep, we can make the terminal look clean without exposing real GitHub URLs. I’m going to add a “recording mode” to the local demo so it runs against real disposable localhost repos, but prints sanitized commands/URLs for screenshots.

That gives us fake public-looking URLs while still exercising the real code path. I’m testing the sanitized mode now so we don’t end up with a pretty screenshot command that secretly breaks.

The first pass hid the source/target URLs in the git-sync commands, but the setup noise still showed temp paths. I’m tightening it so recording mode produces a cleaner terminal: fake repo URLs, git-sync as the binary name, and no disposable temp paths in the visible demo beats.

Yes, and I made that easier.

You can now run the demo in a screenshot/recording-friendly mode:

1
2

cd /Users/rizel/Documents/work/gitsync
GITSYNC_DEMO_SANITIZE_OUTPUT=1 bash docs/demo-local-smart-http.sh

It still runs against real disposable local repos, but the terminal shows clean fake URLs like:

1

git-sync plan --branch main --json https://github.com/acme/source-repo.git https://github.com/acme/target-repo.git

So for the screenshot, you can capture the plan output without exposing any real source/target:

1
2
3
4

"action": "create",
"dryRun": true,
"sourceRef": "refs/heads/main",
"targetRef": "refs/heads/main"

You can customize the fake names too:

1
2
3
4

GITSYNC_DEMO_SANITIZE_OUTPUT=1 \
GITSYNC_DEMO_DISPLAY_SOURCE_URL=https://github.com/entire-dev/source.git \
GITSYNC_DEMO_DISPLAY_TARGET_URL=https://github.com/entire-dev/new-home.git \
bash docs/demo-local-smart-http.sh

That’s probably the cleanest path for your tweet assets: real terminal, real git-sync, fake repo URLs.

i think i want to be able to run

./git-sync plan --branch main --json former-host/former-repo new-host/new-repo

or something like that..that way im not promoting any site

2mo ago·5.1s·4 calls

That’s a good instinct. I’ll make the recording mode print vendor-neutral placeholders exactly in that style, while still using real localhost URLs under the hood so the demo keeps working.

Yep, that’s better. I updated the sanitized demo mode so it now prints exactly vendor-neutral commands like:

1

./git-sync plan --branch main --json former-host/former-repo new-host/new-repo

Run it with:

1
2

cd /Users/rizel/Documents/work/gitsync
GITSYNC_DEMO_SANITIZE_OUTPUT=1 bash docs/demo-local-smart-http.sh

It still runs against real disposable repos under the hood, but the terminal output shows:

source: former-host/former-repo
target: new-host/new-repo

and the screenshot-friendly plan output includes:

1
2
3
4

"action": "create",
"dryRun": true,
"sourceRef": "refs/heads/main",
"targetRef": "refs/heads/main"

That avoids promoting or dunking on any specific host while keeping the demo legible.

i want to be able to type this in myself

2mo ago·9.9s·5 calls

Totally. I’ll make a little recording shell for that: you run one setup command, it drops you into a temporary directory, and then you can literally type ./git-sync plan --branch main --json former-host/former-repo new-host/new-repo yourself.

I added the interactive shell script. I’m checking syntax and running a non-interactive smoke test against the wrapper so we know the exact command you want to type actually succeeds.

Yep. I added a recording shell so you can type the command yourself.

Run this first:

1
2

cd /Users/rizel/Documents/work/gitsync
bash docs/demo-recording-shell.sh

It drops you into a temporary demo directory. Then you can literally type:

1

./git-sync plan --branch main --json former-host/former-repo new-host/new-repo

That command works because the local ./git-sync wrapper maps:

former-host/former-repo -> real disposable source repo
new-host/new-repo       -> real disposable target repo

So the screenshot looks vendor-neutral, but the output is real git-sync output.

I also tested that exact command and it returns the clean plan JSON with "dryRun": true and "action": "create".

it asks for my username and password again. i dont want that. and it has ./ in front of git-sync..i thought we found a way to include it in the script

2mo ago·7.2s·8 calls

Ah, yep, I see the mismatch: the wrapper existed, but the script was still telling you to type ./git-sync. I’m going to put the demo directory on PATH, print commands as git-sync ..., and make the wrapper force non-interactive Git auth so it never wanders into username/password prompts.

I fixed the prompt text and the shell environment. Now the command should be git-sync ... with no ./, because the script puts the temporary wrapper on your PATH.

You’re right. I fixed that.

Now run:

1
2

cd /Users/rizel/Documents/work/gitsync
bash docs/demo-recording-shell.sh

Inside the shell it opens, you can type exactly:

1

git-sync plan --branch main --json former-host/former-repo new-host/new-repo

No ./.

I also set GIT_TERMINAL_PROMPT=0 and verified git-sync resolves to the wrapper inside the demo directory, so it should not ask for username/password. If it does, run this inside the demo shell:

1

command -v git-sync

It should print something like:

/tmp/.../git-sync

why does it name the folder tmp.4M8311LTc3 is that what would happen in real life

2mo ago·5.6s

No, that temp folder name is only from the demo setup.

The script creates disposable local repos with mktemp, so macOS gives it a random directory like:

/tmp/tmp.4M8311LTc3

That is not a git-sync thing, and it would not appear in normal real-life usage.

In real usage you’d run something like:

1

git-sync plan --branch main --json former-host/former-repo new-host/new-repo

or with real remote URLs:

1

git-sync plan --branch main --json https://old-host/org/repo.git https://new-host/org/repo.git

The temporary folder only exists so the demo can create fake source/target repos locally without touching any real host. It is basically the backstage area. Your screenshot/recording should focus on the command and JSON output, not the “Temporary demo directory” line.

oh i wonder if we can name it something more intuitive so when people read the demo they understand

2mo ago·2.4s·9 calls

Yes, that’s a nice polish pass. I’ll change the default demo root from an opaque mktemp path to a readable disposable path under /tmp, while keeping it unique enough not to collide.

It’s better, but macOS still uses a long $TMPDIR. I’m going to make the recording shell default to /tmp/git-sync-recording-demo so it reads cleanly on camera, and clear/recreate it each time unless you override it.

Yep, I changed the recording shell to use a clean, readable folder:

/tmp/git-sync-recording-demo

So now when you run:

1
2

cd /Users/rizel/Documents/work/gitsync
bash docs/demo-recording-shell.sh

it shows:

Temporary demo directory:
  /tmp/git-sync-recording-demo

That’s much easier to understand on camera. It’s still just a disposable local demo workspace, but it looks intentional instead of like random system noise.

feel like it should say former repo or new repo or which ever wouuld be the appropriate oen

2mo ago·6.5s·4 calls

Yes, that reads cleaner. I’ll rename the demo repos themselves from generic source.git / target.git to former-repo.git / new-repo.git, and update the command it tells you to type for checking refs.

Yep, agreed. I updated the recording demo so the local folders now match the story:

/tmp/git-sync-recording-demo/former-repo.git
/tmp/git-sync-recording-demo/new-repo.git
/tmp/git-sync-recording-demo/former-repo-worktree

And the command it suggests now ends with:

1

git --git-dir=new-repo.git show-ref

So on camera, everything lines up:

1
2
3

git-sync plan --branch main --json former-host/former-repo new-host/new-repo
git-sync sync --branch main --json former-host/former-repo new-host/new-repo
git --git-dir=new-repo.git show-ref

I tested the flow after the rename and it works.

rizel@Rizels-MacBook-Pro git-sync-recording-demo % git-sync plan --branch main --json former-host/former-repo new-host/new-repo error: sync: plan: list source refs: request info-refs: Get " http://127.0.0.1:63083/former-repo.git/info/refs?service=git-upload-pack": round trip: dial tcp 127.0.0.1:63083: connect: connection refused

2mo ago·13.9s·4 calls

That means the little local smart-HTTP server behind the fake former-host/former-repo alias died, so the wrapper is still pointing at a localhost port that is no longer listening. I’m going to make that part less fragile by building/running the demo server as a plain binary instead of go run under the shell.

That error means you’re in an old /tmp/git-sync-recording-demo directory after the demo server stopped. The fake command maps to a real localhost server, and that server has to be running.

I updated docs/demo-recording-shell.sh to make the server more stable by building it as a real binary instead of running it through go run.

Start fresh:

1
2

cd /Users/rizel/Documents/work/gitsync
bash docs/demo-recording-shell.sh

Then, inside the shell it opens, type:

1

git-sync plan --branch main --json former-host/former-repo new-host/new-repo

Important bit: don’t open a separate terminal and run it from /tmp/git-sync-recording-demo; use the shell that the script drops you into. When you type exit, the demo server is done.

alright..what would be the next command to run

2mo ago·4.7s

Next run the actual sync:

1

git-sync sync --branch main --json former-host/former-repo new-host/new-repo

For the screen recording, highlight these fields in the output:

1
2
3

"pushed": 1,
"relay": true,
"relayMode": "bootstrap"

Then verify the new repo got the branch:

1

git --git-dir=new-repo.git show-ref

what about probe or something else

2mo ago·6.4s

Yes, probe is a good “before plan” or “after setup” command, especially for screenshots. It shows git-sync can inspect the remotes before deciding what to do.

Run:

1

git-sync probe --json former-host/former-repo new-host/new-repo

If you want tags included:

1

git-sync probe --tags --json former-host/former-repo new-host/new-repo

For the demo sequence, I’d do:

1
2
3
4

git-sync probe --json former-host/former-repo new-host/new-repo
git-sync plan --branch main --json former-host/former-repo new-host/new-repo
git-sync sync --branch main --json former-host/former-repo new-host/new-repo
git --git-dir=new-repo.git show-ref

For tweet/video value:

If you only have 30-60 seconds, I’d skip probe in the video and use it only if you want an extra screenshot. plan is more valuable visually.

if i run sync..i wont be able to run it a second time right?

2mo ago·5.1s

You can run it a second time. It just won’t push anything if nothing changed.

After the first sync, run the same command again:

1

git-sync sync --branch main --json former-host/former-repo new-host/new-repo

You should see something like:

1
2

"pushed": 0,
"skipped": 1

That’s actually a useful demo beat: rerunning is safe/idempotent when the target is already up to date.

Then, to make a more exciting second sync, add a new commit to the former repo:

1
2
3
4

printf 'second line\n' >> former-repo-worktree/README.md
git -C former-repo-worktree add README.md
git -C former-repo-worktree commit -m 'second commit'
git -C former-repo-worktree push origin main

Now run sync again:

1

git-sync sync --branch main --stats --json former-host/former-repo new-host/new-repo

That one should show:

1
2
3
4
5
6
7

"action": "update",
"pushed": 1,
"relay": true,
"relayMode": "incremental",
"stats": {
  "enabled": true
}

yeah but it wont do the same results right? so i gotta do them separately

2mo ago·8.8s

Right. Once you run sync, the demo state changes.

So for clean screenshots/recording, treat them as separate beats:

  1. Before sync Run:
1
2

git-sync probe --json former-host/former-repo new-host/new-repo
git-sync plan --branch main --json former-host/former-repo new-host/new-repo

This shows empty target / planned create / dryRun: true.

  1. First sync Run:
1

git-sync sync --branch main --json former-host/former-repo new-host/new-repo

This shows:

1
2

"pushed": 1,
"relayMode": "bootstrap"
  1. Second immediate sync Run:
1

git-sync sync --branch main --json former-host/former-repo new-host/new-repo

This shows:

1
2

"pushed": 0,
"skipped": 1
  1. Incremental update Add a new commit, then sync:
1
2
3
4
5
6

printf 'second line\n' >> former-repo-worktree/README.md
git -C former-repo-worktree add README.md
git -C former-repo-worktree commit -m 'second commit'
git -C former-repo-worktree push origin main

git-sync sync --branch main --stats --json former-host/former-repo new-host/new-repo

This shows:

1
2
3

"action": "update",
"pushed": 1,
"relayMode": "incremental"

If you want the exact first-sync output again, restart the demo shell:

1
2
3

exit
cd /Users/rizel/Documents/work/gitsync
bash docs/demo-recording-shell.sh

oh okay..i would just need to restart the demo shell for this? to be able to run sync?

2mo ago·9.5s

Exactly. Restarting the demo shell resets the whole local demo back to the beginning.

Do this:

1
2
3

exit
cd /Users/rizel/Documents/work/gitsync
bash docs/demo-recording-shell.sh

Then you’re back to a fresh state where new-repo is empty again, so this will show the first-sync result:

1

git-sync sync --branch main --json former-host/former-repo new-host/new-repo

Expected highlights:

1
2
3

"pushed": 1,
"relay": true,
"relayMode": "bootstrap"

So your workflow can be:

The demo is disposable, so restarting is totally fine.

okay i need to put these things on social media..in a way that's easy to consume whats going on.

Theres a little drama around people leaving github for unreliability right now..so im thinking this will be my first tweet. it's not subject to your feedback or change. it is as is.

For anyone suddenly feeling the urge to move their project somewhere new, we’re open sourcing our latest project, git-sync, today.

A step forward as we build an agent-native git layer where code and agent activity move, sync, and evolve across systems continuously.

2mo ago·14.6s

Got it. Keep tweet 1 exactly as-is. Then I’d make the rest of the thread very concrete and demo-led.

Tweet 2: Concept

Most git migration workflows turn remote-to-remote movement into a local storage problem:

clone a mirror, fetch everything down, push it back up somewhere else.

git-sync is built around a different model: inspect remotes, plan ref updates, then stream the packfile across when it can.

Media: terminal screenshot of plan.

Command shown:

1

git-sync plan --branch main --json former-host/former-repo new-host/new-repo

Crop around:

1
2
3
4

"action": "create",
"dryRun": true,
"sourceRef": "refs/heads/main",
"targetRef": "refs/heads/main"

Tweet 3: Video

The basic flow is intentionally boring:

probe the remotes
preview the update
sync the ref
verify the new repo

That makes it easy to use in scripts, migrations, and agent workflows where you want the output to be inspectable.

Media: 30-60 sec terminal recording.

Run:

1
2
3
4

Highlight:

1 2 3

"pushed": 1, "relay": true, "relayMode": "bootstrap"


**Tweet 4: Incremental Payoff**

And reruns are designed for continuous sync.

Once the target has history, git-sync can advertise target tips as have, fetch what it needs from the source, and push explicit ref updates to the target.


Media: screenshot or short crop from incremental sync.

Command:

1

git-sync sync --branch main --stats --json former-host/former-repo new-host/new-repo


Crop around:

1 2 3 4 5 6

"action": "update", "pushed": 1, "relayMode": "incremental", "stats": { "enabled": true }


**Tweet 5: Try It**

It supports JSON output, branch mapping, tag mirroring, pruning, stats, and safe fast-forward syncs.

Try the local demo:

bash docs/demo-recording-shell.sh

Then type:

1

git-sync plan --branch main --json former-host/former-repo new-host/new-repo

For easiest consumption, I’d use only **two media assets**:

- Tweet 2: screenshot of `plan --json` with `dryRun: true`
- Tweet 3: 30-60 sec video showing `plan → sync → show-ref`

Then Tweet 4 and 5 can stand as text.

too much jargon and not enough why do we care..why would someone want this..but still have the examples

2mo ago·11.3s

Yes. Make it less “protocol internals” and more “what pain does this remove?”

Tweet 2

Moving a repo should not mean babysitting a giant local mirror clone.

With git-sync, you can point at an old home and a new home, preview what would change, then sync the refs directly.

Before it writes anything, you can ask for a plan:

Media: screenshot of:

1

git-sync plan --branch main --json former-host/former-repo new-host/new-repo

Highlight:

1
2

"action": "create",
"dryRun": true

Tweet 3

The happy path is simple:

1. check what exists
2. preview the change
3. sync it
4. verify the new repo has the branch

This is the kind of boring, scriptable workflow you want when infrastructure is having a weird day.

Media: 30-60 sec recording of:

1
2
3
4

**Tweet 4**

And it is not just for one-off moves.

Run it again and git-sync can tell you nothing changed. Add a new commit, run it again, and it syncs the update.

That makes it useful for migrations, backup flows, mirrors, and agent systems that need code to keep moving between places.


Optional screenshot/video crop:

1 2 3

"action": "update", "pushed": 1, "relayMode": "incremental"


**Tweet 5**

A few nice bits for real workflows:

Try the local demo:

bash docs/demo-recording-shell.sh


This still shows the commands, but the story is: less babysitting, preview before writing, scriptable when things are unstable, and useful beyond a one-time migration.

oh no theyre not going to have access to the local demo..thats just for me

2mo ago·8.5s

Ah yes, then don’t mention the local demo at all in the public thread. The commands are visual examples, not instructions for them to run.

Here’s a cleaner public version after your tweet 1:

**Tweet 2**

Moving a repo should not mean babysitting a giant local mirror clone.

git-sync lets you point at an old home and a new home, preview what would change, then sync the refs directly.

Before it writes anything, you can ask for a plan:


Media: screenshot of terminal:

1

git-sync plan --branch main --json former-host/former-repo new-host/new-repo


**Tweet 3**

That plan is meant to be readable by both humans and scripts.

You can see which branch would move, which ref would be created or updated, and that dryRun is true before anything touches the target.


Media can be same screenshot crop, or no media.

**Tweet 4**

Then the actual sync is just as explicit.

git-sync reports what changed, what was skipped, whether the operation used relay, and enough structured output to wire it into migration jobs, backups, mirrors, or agent workflows.


Media: 30-60 sec video showing:

1 2 3

git-sync plan ... git-sync sync ... git --git-dir=new-repo.git show-ref


**Tweet 5**

And reruns are boring in the best way.

If nothing changed, nothing gets pushed. If the source moved forward, git-sync can sync the update and report it as an incremental run.

That makes it useful beyond one-time migrations: projects can keep moving between systems.


**Tweet 6**

It supports JSON output, branch mapping, tag mirroring, pruning, stats, and safe fast-forward syncs by default.

Repo here:

```

For media, I’d use:

Keep the fake URLs in the terminal. They read as placeholders and avoid naming any host.

Tweet 1:

For anyone suddenly feeling the urge to move their project somewhere new, we’re open sourcing our latest project, git-sync, today.

A step forward as we build an agent-native git layer where code and agent activity move, sync, and evolve across systems continuously.

< picture>

Tweet 2:

Most git migration tools assume you’ll make a local mirror clone, fetch everything down, then push it back up somewhere else. But moving a repo should not mean babysitting a giant local mirror clone.

git-sync lets you point at an old home and a new home, preview what would change, then sync the refs directly.

Before it makes any changes, you can ask for a plan that’s meant to be readable by both humans and scripts. You can see which branch would move, which ref would be created or updated, and that dryRun is true before anything touches the target

[screenrecording of running plan and highlight ref, dryRun etc]

Tweet 3:

The actual sync is just as explicit.

git-sync reports what changed, what was skipped, whether the operation used relay, and enough structured output to wire it into migration jobs, backups, mirrors, or agent workflows.

And reruns are boring in the best way. If nothing changes, nothing gets pushed.

You can try it here. Happy syncing! [link to repo]

[screen recording of running git-sync]

2mo ago·7.1s

This is close. I’d tighten Tweet 2 and Tweet 3 so they’re easier to read on X, especially with media attached. Your current Tweet 2 is doing a lot in one block.

Tweet 2

Most git migration tools assume you’ll make a local mirror clone, fetch everything down, then push it back up somewhere else.

But moving a repo should not mean babysitting a giant local mirror clone.

git-sync lets you point at an old home and a new home, preview what would change, then sync the refs directly.

Before it makes any changes, you can ask for a plan that’s readable by both humans and scripts.

Media: screen recording of:

1

git-sync plan --branch main --json former-host/former-repo new-host/new-repo

Highlight:

1
2
3
4

"sourceRef": "refs/heads/main",
"targetRef": "refs/heads/main",
"action": "create",
"dryRun": true

Tweet 3

The actual sync is just as explicit.

git-sync reports what changed, what was skipped, whether it used relay, and enough structured output to wire into migration jobs, backups, mirrors, or agent workflows.

And reruns are boring in the best way: if nothing changed, nothing gets pushed.

Try it here: <link>

Media: screen recording of:

1
2

git-sync sync --branch main --json former-host/former-repo new-host/new-repo
git-sync sync --branch main --json former-host/former-repo new-host/new-repo

Highlight first run:

1
2
3

"pushed": 1,
"relay": true,
"relayMode": "bootstrap"

Highlight second run:

1
2

"pushed": 0,
"skipped": 1

I’d avoid “Happy syncing!” here. The rest of the copy has a serious, useful systems vibe; “Try it here” is cleaner.

wish it could end cute than just try it here

2mo ago·5.6s

Yes, keep the ending warmer. A few options:

Give it a spin:
<link>

Happy syncing.

Repo is here:
<link>

May your mirrors be boring.

Code is here:
<link>

Move carefully, sync often.

Repo is here:
<link>

Here’s to less repo-moving stress.

Try it here:
<link>

May your next migration be uneventful.

My pick for the thread:

Repo is here:
<link>

May your next migration be boring.

It’s cute, but still fits the “boring in the best way” line.

we need a screen recording or something for the first tweet

2mo ago·11.3s

For Tweet 1, I’d use a short hero screen recording, not a screenshot.

The goal is: “this is real, it moves refs, and the command is simple.”

Tweet 1 Recording: 20-30 Seconds

Start fresh:

1
2

cd /Users/rizel/Documents/work/gitsync
bash docs/demo-recording-shell.sh

Then record yourself typing/running:

1

git-sync plan --branch main --json former-host/former-repo new-host/new-repo

Pause/highlight:

1
2

"action": "create",
"dryRun": true

Then run:

1

git-sync sync --branch main --json former-host/former-repo new-host/new-repo

Pause/highlight:

1
2
3

"pushed": 1,
"relay": true,
"relayMode": "bootstrap"

Then run:

1

git --git-dir=new-repo.git show-ref

End on:

refs/heads/main

That gives the first tweet a complete tiny story:

preview -> sync -> new repo has the branch

For Tweet 2, you can still use the plan recording/screenshot more zoomed in. For Tweet 3, use the rerun/idempotent sync clip. But Tweet 1 should be the broad “look, it works” moment.

but i thought the third tweet was already going to to plan, sync?

Tweet 1:

For anyone suddenly feeling the urge to move their project somewhere new, we’re open sourcing our latest project, git-sync, today.

A step forward as we build an agent-native git layer where code and agent activity move, sync, and evolve across systems continuously.

< picture>

Tweet 2:

Most git migration tools assume you’ll make a local mirror clone, fetch everything down, then push it back up somewhere else.

But moving a repo should not mean babysitting a giant local mirror clone.

git-sync lets you point at an old home and a new home, preview what would change, then sync the refs directly.

Before it makes any changes, you can ask for a plan that’s readable by both humans and scripts.

[screenrecording of running plan and highlight ref, dryRun etc]

Tweet 3:

The actual sync is just as explicit.

And reruns are boring in the best way: if nothing changed, nothing gets pushed.

Give it a spin:

[screen recording of running git-sync]

2mo ago·8.3s

You’re right. Don’t duplicate plan → sync on Tweet 1 if Tweet 2 and 3 already carry those demos.

For Tweet 1, use a hero terminal screenshot, not a full flow recording.

Best Tweet 1 media:

1

git-sync

or:

1

git-sync --help

But since the CLI currently prints help as an error, better to make the screenshot from the tutorial/demo shell showing the clean command and result summary from sync.

I’d use a still screenshot with this visible:

1

git-sync sync --branch main --json former-host/former-repo new-host/new-repo

and crop around:

1
2
3
4

"pushed": 1,
"relay": true,
"relayMode": "bootstrap",
"protocol": "v2"

That gives Tweet 1 the “what is this?” visual without stealing Tweet 2’s plan story or Tweet 3’s rerun story.

Then the thread media becomes:

Tweet 1 media Hero screenshot: git-sync sync ... showing pushed, relay, relayMode.

Tweet 2 media Screen recording: only plan --json, highlighting sourceRef, targetRef, action, dryRun.

Tweet 3 media Screen recording: actual sync + rerun:

1
2

git-sync sync --branch main --json former-host/former-repo new-host/new-repo
git-sync sync --branch main --json former-host/former-repo new-host/new-repo

Highlight: First run:

1
2

"pushed": 1,
"relayMode": "bootstrap"

Second run:

1
2

"pushed": 0,
"skipped": 1

So: Tweet 1 is the product glamour shot. Tweet 2 is “preview before writing.” Tweet 3 is “sync + safe rerun.”

does this run in the background at all

2mo ago·5.0s

No. git-sync itself does not run in the background.

It’s a command you run, it does the sync, prints output, and exits. So for the thread, describe it as something you can put into automation, jobs, scripts, CI, migration workflows, etc., but not as a background daemon.

In our demo shell, there is a tiny local HTTP server running in the background, but that’s only for the fake local recording setup. Real git-sync usage is just:

1
2

git-sync plan ...
git-sync sync ...

Run → output → exit.

are these answers in the readme?

some other questions that you might get asked: does it shallow clones/syncs or full historical data syncs as well is it just refs or objects as well? (demo just shows a ref but i assume objects too) is it bidirectional? or just one way? does it support all actions? (create, modify, delete)? how does it scale? if it's an in-memory store, does it stream through the in-memory store by writing to it and then reading from it to write to the target? or does it first dump everything into the in-memory store? how long does it take for a medium sized repo? how does it deal with partial successes? is it atomic? does it support SSH?

i haven't been involved with this at all but this is what first comes to mind if I was thinking about using it. i'm sure there are other questions too. you also don't have to answer all of these in the tweet thread, but probably in the readme would be good.

2mo ago·5.8s·6 calls

Good questions, and they’re exactly the kind of “okay but can I trust this?” questions people will ask. I’ll check what the README already covers, then I’ll add a focused FAQ where the answers are missing or buried.

A lot of the answers exist, but they’re scattered between the README, architecture doc, and protocol doc. I’m going to add a plain-language FAQ to the README so people do not have to reverse-engineer the important caveats.

<turn_aborted> The user interrupted the previous turn on purpose. Any running unified exec processes may still be running in the background. If any tools/commands were aborted, they may have partially executed. </turn_aborted>

2mo ago

e2728aeMove detailed usage docs out of README\ \ Entire-Checkpoint: 1ecffd82af56+140/-119

59826badocs: add README FAQ\ \ Entire-Checkpoint: e0af21de41fb+38

f3222cbAdd git sync demo video\ \ Entire-Checkpoint: 8a21e9e6fa95+2