4 ms·
> Track the head of each branch at each point in "monotonic server time oof talk about over-engineering. What is the point? Just don't allow force pushes to pr
by nsfyn55 11y ago
> Track the head of each branch at each point in "monotonic server time
oof talk about over-engineering. What is the point? Just don't allow force pushes to protected branches is a much simpler model than. "Keep a bunch of bookkeeping meta data in the event of an unanticipated force push". All this complexity would only save you during the span of time those objects were collectible but not yet collected.
- ajross 11y agoNot really following your point. What I described could be implemented by a post-update hook that just ran "git rev-parse HEAD" and stuffed the result into a database somewhere. If anything it's significantly easier to implement than an authorization model.
- nsfyn55 11y agoI'm not following where you are going. If these database records point to objects in the git database. How will you synchronize garbage collection and the state of the database?
- ajross 11y agoWith pointers out of the refs directory, the way you do it for everything else? Are you deliberately trying to start a fight? This isn't a complicated subject...
- nsfyn55 11y agoNot trying to start a fight, I just don't understand your solution. What does git do with orphaned entries in the refs directory when it garbage collects? Does it delete them? How would you synchronize your database pointers with garbage collection? Presumably when this happened you'd have to interrupt it or you'd have to delete those records from your database. Then they'd really be lost right?