On Tue, Dec 17, 2024 at 4:51 PM Shubham Kanodia <shubham.kanodia10@xxxxxxxxx> wrote: > > On Tue, Dec 17, 2024 at 1:11 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > > Patrick Steinhardt <ps@xxxxxx> writes: > > > > > If we want to have such a feature I'd thus claim that it would be most > > > sensible to make it opt-in rather than opt-out. I wouldn't want to be > > > surprised by remote refs vanishing after going to bed, but may be okay > > > with it when I explicitly ask for it. > > > > > > At that point one has to raise the question whether it is still all that > > > useful compared to running `git remote prune` manually every now and > > > then. Mostly because explicitly configuring maintenance is probably > > > something that only power users would do, and those power users would > > > likely know to prune manually. > > > > I am 100% in agreement with your reasoning. If this thing is to > > exist, it has to be opt-in. We also need to add ample warning why > > doing this asynchronously behind user's back while the user could be > > working in the same repository is prone to cause surprises in the > > documentation in big red letters. > > > > I however am OK with the idea of having it as an optional "task" > > that is disabled by default in "git maintenance". "git maintenance" > > can be viewed as a platform-neutral way to set up scheduled tasks. > > > > A user may be a Git expert who knows what `git remote prune` does, > > and understands and accepts the risk of confusion doing so without > > explicit "do it now" from the end-user, but may not be a Linux or a > > macOS or a Windows expert to know how to write crontab or its > > equivalents on various schemes to define scheduled tasks. > > > > Thanks. > > Thanks for sharing your thoughts here. For some context — I currently > look after git performance for a very large repository (60k+ refs) > with a lot of active developers. > I've observed that while power git users keep their repository tidy > even without runnining maintenance, the majority of users infact don't > know (or execute these), and > run into performance issues. Easier fleet management was perhaps was > one of the motivations behind adding this to `git-maintenance`. > > While its pretty rare that someone relies on a `refs/remote/*` > reference (without creating a local copy of it in `refs/heads`), I can > see why it can be surprising and an opt-in > should be okay for me. > > Thanks, > Shubham K
