Yup, it's not the greatest solution for teams as a central issue tracker.
The main reason I included the mention of small teams is that you can opt out of committing ./ghist, keeping it on your machine only and use it to track your own set of work across multiple agent sessions. It then becomes more of a disposable tool you can use to get big chunks of work done with persistent task memory.
Going with sqlite might not have been the best decision either as it's ultimately a binary file that can't be diff'd. Potentially JSON might have been a better solution for this.
The problem with keeping a issue tracker decentralized in your git checkout is that it doesnt scale.
You’d need to commit and push, and everybody else working on the project need to pull in your commits in order to see the changes.
This makes working with feature branches break immediately, and it makes cooperation really hard in all kinds of ways.
It can work, as long as you dont use branches and as long as you are solo, I guess.
The project readme suggests it would be a good fit for small teams. I beg to differ.
Yup, it's not the greatest solution for teams as a central issue tracker.
The main reason I included the mention of small teams is that you can opt out of committing ./ghist, keeping it on your machine only and use it to track your own set of work across multiple agent sessions. It then becomes more of a disposable tool you can use to get big chunks of work done with persistent task memory.
Going with sqlite might not have been the best decision either as it's ultimately a binary file that can't be diff'd. Potentially JSON might have been a better solution for this.
> Going with sqlite might not have been the best decision
Many have tried out this general idea. I myself evaluated git-bug for a few days i 2018 but I ran into issues I tried to raise in my previous comment.
The data format ypu chose is not even the main issue here, but binary data that keeps changing is generally always unfit for source control.