3 ms·

There are a ton of interesting ideas in the README - things like the way it uses the birthday paradox to decide when to increase the length of the hash IDs. T

by simonw 1y ago

There are a ton of interesting ideas in the README - things like the way it uses the birthday paradox to decide when to increase the length of the hash IDs. This tool works by storing JSONL in a .beads/ folder. I wonder if it could work using a separate initially-empty "beads" branch for this data instead? That way the beads data (with its noisy commit history) could travel with the repository without adding a ton of noise to the main branch history. The downside of that is that you wouldn't be able to branch the .beads/ data or keep it synchronized with main on a per-commit basis. I haven't figured out if that would break the system.

wowamit 1y ago
The way I read it is beads steers agents to make use of the .beads/ folder to stay in sync across machines. So, my understanding is a dedicated branch for beads data will break the system.
- simonw 1y ago
  But wouldn't that dedicated branch, pushed to origin, also work for staying synced across multiple machines?
  - wowamit 1y ago
    The way I understand this, when the agent runs `bd onboard` at startup, it gets the instructions from beads, which might refer to data files in the beads directory. Keeping them in sync via a separate branch would be an unnecessary overhead. Right?
    - simonw 1y ago
      I don't see it as extra overhead - it just changes the git one-liner they use to push and pull their issue tracking content by a few characters. I like the idea of keeping potentially noisy changes out of my main branch history, since I look at that all the time.
      - wowamit 1y ago
        You are right. I dug through the document some more. The setup, as mentioned for protected branches [1], should ideally work without much overhead. It does suggest merging back to main, but the FAQ also mentions that the frequency can be decided individually. [1] https://github.com/steveyegge/beads/blob/main/docs/PROTECTED_BRANCHES.md https://github.com/steveyegge/beads/blob/main/docs/PROTECTED...
  - amonks 1y ago
    Depends what you mean by “synced”—do you want your beads state to be coupled with commits (eg: checking out an old commit also shows you the beads state at that snapshot)? Using a separate branch would decouple this. I think the coupling is a nice feature, but it isn’t a feature that other bug trackers have, so using a separate branch would make beads more like other bugtrackers. If you see the coupling as noise, though, then it sounds like that is what you want.

by simonw 1y ago

wowamit 1y ago

The way I read it is beads steers agents to make use of the .beads/ folder to stay in sync across machines. So, my understanding is a dedicated branch for beads data will break the system.

simonw 1y ago
But wouldn't that dedicated branch, pushed to origin, also work for staying synced across multiple machines?
- wowamit 1y ago
  The way I understand this, when the agent runs `bd onboard` at startup, it gets the instructions from beads, which might refer to data files in the beads directory. Keeping them in sync via a separate branch would be an unnecessary overhead. Right?
  - simonw 1y ago
    I don't see it as extra overhead - it just changes the git one-liner they use to push and pull their issue tracking content by a few characters. I like the idea of keeping potentially noisy changes out of my main branch history, since I look at that all the time.
    - wowamit 1y ago
      You are right. I dug through the document some more. The setup, as mentioned for protected branches [1], should ideally work without much overhead. It does suggest merging back to main, but the FAQ also mentions that the frequency can be decided individually. [1] https://github.com/steveyegge/beads/blob/main/docs/PROTECTED_BRANCHES.md https://github.com/steveyegge/beads/blob/main/docs/PROTECTED...
- amonks 1y ago
  Depends what you mean by “synced”—do you want your beads state to be coupled with commits (eg: checking out an old commit also shows you the beads state at that snapshot)? Using a separate branch would decouple this. I think the coupling is a nice feature, but it isn’t a feature that other bug trackers have, so using a separate branch would make beads more like other bugtrackers. If you see the coupling as noise, though, then it sounds like that is what you want.