[GH-ISSUE #111] In production builds Git AI should refuse to overwrite any existing note #48

New issue

Closed

opened 2026-03-02 04:11:28 +03:00 by kerem · 1 comment

kerem commented

2026-03-02 04:11:28 +03:00

Owner

Originally created by @acunniffe on GitHub (Oct 16, 2025).
Original GitHub issue: https://github.com/git-ai-project/git-ai/issues/111

@svarlamov and I realized

that if a remote process wanted to update notes (to add more information or remove a prompt), it could contend with clones. Each cloned version would try to overwrite the cloud changes -- last would win, but there's more of them.
two clones could disagree about authorship log if there were bugs or new features added. We don't want them in contention. Last can win now

Solution

First check for a note with the same name, if empty write.

Originally created by @acunniffe on GitHub (Oct 16, 2025). Original GitHub issue: https://github.com/git-ai-project/git-ai/issues/111 @svarlamov and I realized - that if a remote process wanted to update notes (to add more information or remove a prompt), it could contend with clones. Each cloned version would try to overwrite the cloud changes -- last would win, but there's more of them. - two clones could disagree about authorship log if there were bugs or new features added. We don't want them in contention. Last can win now Solution - First check for a note with the same name, if empty write.

kerem closed this issue

2026-03-02 04:11:29 +03:00

kerem commented

2026-03-02 04:11:29 +03:00

Author

Owner

@svarlamov commented on GitHub (Nov 3, 2025):

Actually, since we moved to the git notes-based approach from the earlier refs-based approach, this question around remote changes being overwritten by outdated clones is no longer an issue. Tested to ensure that clones will pick up the changes and merge them into their own trees before pushing again, so the changes are preserved without issue.

@svarlamov commented on GitHub (Nov 3, 2025): Actually, since we moved to the git notes-based approach from the earlier refs-based approach, this question around remote changes being overwritten by outdated clones is no longer an issue. Tested to ensure that clones will pick up the changes and merge them into their own trees before pushing again, so the changes are preserved without issue.

kerem referenced this issue

2026-03-02 04:13:00 +03:00

[PR #48] fmt, update git commands compat #223