Save Milestone feature

[batnom]

While it is amazing that BB commits to git every change, these commit messages can look samey and there are a lot of them.

Couple this with some rate-limiting issues and Claude would return Error occurred: Request failed after multiple retries.. Continuing conversation." every now and then for me, but also leave the build in a broken state as it was in the middle of multi-step and multi-file spanning changes.

To ensure I always have a clear last known working build I can roll back to, I have found myself I found myself doing a manual git add . and git commit "blah is working" to name this as a milestone to find in the log easily.

I thought this might be a quick feature to get added to the Web UI. Possibly even a list of milestones and "checkout" or "revert to here" options.

[cngarrison]

I've been thinking about a "git" tool to create new branches at start of conversations and/or statements. But there are many considerations, such as when or if to merge back to the working branch. Having an 'undo' using git revert would also be useful, but again there are a few considerations.

The run_command tool can also run git commands, which is why there is not a git-specific tool yet. The run_command tool is much more flexible. A possible solution is to combine the run_command tool with the "guidelines" file.

Modify the project config.yaml to allow git to be run as a command and also specify a guidelines file.

api:
  toolConfigs:
    run_command:
      allowedCommands:
        - 'git'
project:
  llmGuidelinesFile: GUIDELINES.md

In the GUIDELINES.md file, add instructions to use git:

IMPORTANT:
Before every round of changes that modify files in the project be sure to run `git branch`. 
At end of each round of changes, ask the user for confirmation, and then merge the branch back to 'working' branch.

Note, the guidelines file is useful for a range of instructions relevant to the project. For some examples, see the files used when developing BB.

• https://github.com/Beyond-Better/bb/blob/main/CONVENTIONS-short.md
• https://github.com/Beyond-Better/bb/blob/main/CONVENTIONS.md

The guidelines file is included in the system prompt with every conversation.

[cngarrison]

I thought this might be a quick feature to get added to the Web UI. Possibly even a list of milestones and "checkout" or "revert to here" options.

We have a number of ideas for shortcuts and features for the UI. We'll include this on the list.

[metachip]

Okay, I'm a raw newbie when it comes to BB but here's a suggested workflow for BB's Git management that I think could work:

BB could maintain three distinct levels of Git history:

1. Conversation branches (like auto-saves) - capturing every AI change
2. Working branch (like explicit saves) - collecting successful conversations
3. Main branch (like releases) - clean, human-readable history

Each conversation would start on its own branch. When successful, its changes get squashed and merged to 'working'. Periodically, 'working' gets cleaned up and merged to 'main'. Only main is pushed to remote, or perhaps working as well, but for a clean upstream I would say probably not. The conversation branches definitely not. To avoid mistakes, one could git config conversation/* no-push or use worktree or stash for conversations instead of branches.

This would preserve BB's rapid albeit messy (from a human PoV) development style whilst maintaining a clean history. The "Save Milestone" feature would then make more sense as a tag on the working branch, marking known-good states. This would give us the best of both worlds: detailed history when needed, clean history for humans, and reliable recovery points.

[cngarrison]

BB could maintain three distinct levels of Git history:

1. Conversation branches (like auto-saves) - capturing every AI change

BB does this already (for projects set to type: git)

2. Working branch (like explicit saves) - collecting successful conversations

This is the technique I've been thinking about creating a tool for. The LLM could then automate some basic git maintenance tasks.

3. Main branch (like releases) - clean, human-readable history

Are you thinking about tagged commits after a merge, or something similar? BB already uses Haiku to write commit messages based on diffs for latest commit (for the auto-saves); getting it to write a commit message based on the git history since last tagged release is an interesting idea.

Each conversation would start on its own branch. When successful, its changes get squashed and merged to 'working'.

Creating a new branch using a "git tool" would be easy enough, but I'm not sure how to handle concurrent conversations. When switching between conversations in BB, would that enforce a branch change in the git repo? Using worktrees is an interesting option to avoid that requirement, but it runs into the problem of how BB recognizes a "project", which generally means a directory with a git repo. BB does support parent directories with multiple git repos; maybe that could extend to a single repo with multiple worktrees.

I'm keen to collect some use-cases for the variations of how people use git repos in relation to BB projects.

[metachip]

Worktrees can be disambiguated from the root git repo (from the pointer file in .git local to each worktree). I'll give it some thought over the next couple of days but at this point I'm convinced the worktree approach, on a single git repo, is the very best way to handle concurrency when it's between one human and the model via BB on one machine.Relatedly I had an in-depth conversation with a colleague who may have a very good use case. Likewise another associate in the US. I have a call with them on Tuesday.Bottom line: I think I may be able to pull together two or three candidates as high-quality users of BB to help with our DD.On the question of multiple levels, the type you call "git" I think should not appear in pushed repositories at all. I have looked through the commit history of the BB project, and not withstanding the relative clarity of haiku generated commit messages, they still appear as verbose "forests of conversation" within squashed commits.It's a level of detail that is off-putting for someone who is not engaged with the process and workflow the generated it and I believe should only be something that is pushed to a shared repository "intentionally". And doing this should be very rare!Otherwise the shared repo devolves to being just "noise".I suspect it may be something which newcomers who find BB through the GitHub front door would find quite offputting. I did. In general, the best shared repositories in my view are those run by a small team who are committed to a very clear narrative in the sense of the rebased commits they actually push to the shared repo.The commit history should read like a book.Especially on master.My 2c for now.On 10 Jan 2025, at 10:47, 'Charlie Garrison' via Office ***@***.***> wrote: BB could maintain three distinct levels of Git history: Conversation branches (like auto-saves) - capturing every AI change BB does this already (for projects set to type: git) Working branch (like explicit saves) - collecting successful conversations This is the technique I've been thinking about creating a tool for. The LLM could then automate some basic git maintenance tasks. Main branch (like releases) - clean, human-readable history Are you thinking about tagged commits after a merge, or something similar? BB already uses Haiku to write commit messages based on diffs for latest commit (for the auto-saves); getting it to write a commit message based on the git history since last tagged release is an interesting idea. Each conversation would start on its own branch. When successful, its changes get squashed and merged to 'working'. Creating a new branch using a "git tool" would be easy enough, but I'm not sure how to handle concurrent conversations. When switching between conversations in BB, would that enforce a branch change in the git repo? Using worktrees is an interesting option to avoid that requirement, but it runs into the problem of how BB recognizes a "project", which generally means a directory with a git repo. BB does support parent directories with multiple git repos; maybe that could extend to a single repo with multiple worktrees. I'm keen to collect some use-cases for the variations of how people use git repos in relation to BB projects. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[cngarrison]

It's a level of detail that is off-putting for someone who is not engaged with the process and workflow the generated it and I believe should only be something that is pushed to a shared repository "intentionally".

Agreed! For my usage, I always squash branches before merging for that very reason. But it's a manual process that many users won't be willing to do. So getting BB (via tool usage) to manage that makes a lot of sense. There's so many different ways that people want git to behave though, and so many chances of merge conflicts, etc - real world usage is needed to understand how to best solve it.