[Home](/content/site-root.html)
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:
- [docs/tutorial.md](/content/Users/rizel/Documents/work/gitsync/docs/tutorial.md): a practical tutorial covering setup, build/test, core commands, hosted-remote usage, demo scenarios, output fields, and benchmark usage.
- [docs/demo-local-smart-http.sh](/content/Users/rizel/Documents/work/gitsync/docs/demo-local-smart-http.sh): a runnable local demo that creates disposable source/target repos, serves them over Git smart HTTP, runs `plan`, `sync`, incremental sync, branch mapping, and verifies target refs.
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:
- a bare source repo
- a bare target repo
- a working repo with commits
- a local smart HTTP server
- a real `git-sync plan`
- a real `git-sync sync`
- an incremental sync
- a branch mapping demo from `main` to `stable`
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.
2. **Preview Before Changing Anything**
Run:
```
1
./git-sync plan --branch main --json
```
Screenshot the JSON `plans` section showing:
- `action: "create"`
- `dryRun: true`
- `sourceRef`
- `targetRef`
This is a great “automation-friendly and safe” moment.
3. **Initial Sync**
Run:
```
1
./git-sync sync --branch main --json
```
Screenshot:
- `pushed: 1`
- `relay: true`
- `relayMode: "bootstrap"`
This shows the big value: it bootstraps the empty target through relay.
4. **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.
5. **Incremental Sync**
Add a second commit to source, push it, then run:
```
1
./git-sync sync --branch main --stats --json
```
Screenshot:
- `action: "update"`
- `relayMode: "incremental"`
- `stats.enabled: true`
This is probably the best value shot: reruns only move the delta, with stats.
6. **Branch Mapping**
Run:
```
1
./git-sync sync --map main:stable --json
```
Screenshot:
- `sourceRef: "refs/heads/main"`
- `targetRef: "refs/heads/stable"`
- final `show-ref` showing both `main` and `stable`
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:
- **0:00-0:20**: “Here’s the problem: source has refs, target is empty.”
- **0:20-0:50**: Run `plan --json` and show it previews the exact ref action.
- **0:50-1:20**: Run initial `sync` and highlight `pushed: 1`, `relay: true`, `relayMode: "bootstrap"`.
- **1:20-1:45**: Show target now has `refs/heads/main`.
- **1:45-2:20**: Add a commit, rerun sync, highlight `relayMode: "incremental"` and `stats`.
- **2:20-2:45**: Show `--map main:stable` and final refs.
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.”
2. **Bootstrap Sync**
Run `sync --json`.
Highlight:
```
1
2
3
"pushed": 1,
"relay": true,
"relayMode": "bootstrap"
```
Message: “Seed an empty target through relay.”
3. **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.
```
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.
```
```
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:
- `an source` → `a source`
- Added `It’s` before “a step forward” so the sentence lands cleaner.
- Otherwise I’d keep it. The timing/context is obvious without naming GitHub reliability directly.
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](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.
```
**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:
- `"dryRun": true`
- `"relayMode": "bootstrap"`
- `"relayMode": "incremental"`
- `"stats": { "enabled": true }`
**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:
- **Tweet 2 screenshot**: simple visual/diagram or `plan --json`
- **Tweet 3 video**: the terminal demo
- **Tweet 4 screenshot**: incremental JSON output
If you only want **one screenshot and one video**, then use:
- Screenshot on Tweet 2: `plan --json` showing safe preview
- Video on Tweet 3: plan → sync → incremental sync
- Tweet 4 no media, just repo link + “try the demo” command.
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:
- **Screenshot on Tweet 2:**`plan --json` with `"dryRun": true`
- **Video on Tweet 3:**`sync` bootstrap → incremental relay → final `show-ref`
- **Tweet 4:** no media, just the “built for automation” payoff and demo command:
```
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
```
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//.git
https://github.com//.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](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](/content/Users/rizel/Documents/work/gitsync/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:
- `probe`: “can inspect source + target”
- `plan`: “can preview exact ref updates”
- `sync`: “can execute via bootstrap relay”
- `show-ref`: “target really changed”
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`.
2. **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"
```
3. **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
```
4. **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:
- Restart shell → capture `plan`
- Restart shell → capture first `sync`
- Restart shell → record the full flow, if needed
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
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:
- JSON output for automation
- branch mapping with `--map main:stable`
- tag mirroring
- pruning
- stats
- safe fast-forward syncs by default
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:
- **Screenshot on tweet 2:**`plan --json`, crop around `action: create` and `dryRun: true`
- **Video on tweet 4:**`plan → sync → show-ref`, around 30-45 seconds
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:
```
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:
Happy syncing.
```
```
Repo is here:
May your mirrors be boring.
```
```
Code is here:
Move carefully, sync often.
```
```
Repo is here:
Here’s to less repo-moving stress.
```
```
Try it here:
May your next migration be uneventful.
```
My pick for the thread:
```
Repo is here:
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.
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.
2mo ago
[e2728aeMove detailed usage docs out of README\\
\\
Entire-Checkpoint: 1ecffd82af56+140/-119](/content/gh/entireio/git-sync/commit/e2728ae0695918401fb021558e7ac7394b0d391b/index.html)
[59826badocs: add README FAQ\\
\\
Entire-Checkpoint: e0af21de41fb+38](/content/gh/entireio/git-sync/commit/59826ba3c2fc0c438377372f8fca3eaaecc0624d/index.html)
[f3222cbAdd git sync demo video\\
\\
Entire-Checkpoint: 8a21e9e6fa95+2](/content/gh/entireio/git-sync/commit/f3222cbccfdc7c0d65117744a74f78638eea56a0/index.html)