4 ms·

At risk of sounding curmudgeonly, I can't help but feel like `git maintenance` is a bit of unneeded feature creep. Does it sound useful? Sure. But should it par

At risk of sounding curmudgeonly, I can't help but feel like `git maintenance` is a bit of unneeded feature creep. Does it sound useful? Sure. But should it part of git itself, when its functionality could be easily achieved instead by crontabbing a relatively simple shell script that runs existing git commands? I feel like the answer is "No.". Of course, not everyone would go out of their way to write the aforementioned shell script; they even address this directly in the release: > You could manage these data-structures yourself, but you might not want to invest the time figuring out when and how to do that. On the other hand, not everyone will use `git maintenance`, so by the same token you could argue it's unnecessary bloat.

powersnail 6y ago
I'd argue that if we eliminate all features that not everyone will use, we'd have a bare bone tool that's barely useful, except to those who just like it so much that they'll implement all the features they need via scripts. Since it's not something that turns itself on, eating your RAM behind your back, or slowing the computer silently, I'd say let the feature creep in as long as the maintainers are happy to maintain it.
teraflop 6y ago
As noted in the documentation[1], doing this in the background on a repository that might be simultaneously in use is a bit non-trivial. You can do it using commands that already exist in Git, but doing so safely requires knowing a fair amount of details about Git's internals. By the same argument, you could say that it's overkill to have "git commit" when we could instead just construct commit objects using the lower-level plumbing commands. This seems like a relatively small feature (about 2K lines of code by my count, a great deal of which is tests and docs) that results in a big quality-of-life improvement for anyone who works on large repositories. [1]: https://git-scm.com/docs/git-maintenance https://git-scm.com/docs/git-maintenance
glandium 6y ago
`git maintenance` does set a crontab. Per the doc, it sets up the following: 0 1-23 * * * "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=hourly 0 0 * * 1-6 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=daily 0 0 * * 0 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=weekly `git for-each-repo` was a useful addition in 2.30, by the way.
- captn3m0 6y ago
  for-each-repo looks great, I'm considering moving my karn[0] configuration to this instead. [0]: https://github.com/prydonius/karn https://github.com/prydonius/karn

powersnail 6y ago

I'd argue that if we eliminate all features that not everyone will use, we'd have a bare bone tool that's barely useful, except to those who just like it so much that they'll implement all the features they need via scripts. Since it's not something that turns itself on, eating your RAM behind your back, or slowing the computer silently, I'd say let the feature creep in as long as the maintainers are happy to maintain it.

teraflop 6y ago

As noted in the documentation[1], doing this in the background on a repository that might be simultaneously in use is a bit non-trivial. You can do it using commands that already exist in Git, but doing so safely requires knowing a fair amount of details about Git's internals. By the same argument, you could say that it's overkill to have "git commit" when we could instead just construct commit objects using the lower-level plumbing commands. This seems like a relatively small feature (about 2K lines of code by my count, a great deal of which is tests and docs) that results in a big quality-of-life improvement for anyone who works on large repositories. [1]: https://git-scm.com/docs/git-maintenance https://git-scm.com/docs/git-maintenance

glandium 6y ago

`git maintenance` does set a crontab. Per the doc, it sets up the following: 0 1-23 * * * "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=hourly 0 0 * * 1-6 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=daily 0 0 * * 0 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=weekly `git for-each-repo` was a useful addition in 2.30, by the way.

captn3m0 6y ago
for-each-repo looks great, I'm considering moving my karn[0] configuration to this instead. [0]: https://github.com/prydonius/karn https://github.com/prydonius/karn