Re: [PATCH 01/15] run-job: create barebones builtin
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Apr 7, 2020, 14:30 UTC
- Message-ID
- <nycvar.QRO.7.76.6.2004071623400.46@tvgsbejvaqbjf.bet>
- In-Reply-To
- <20200407141600.GA1963@danh.dev>
Hi,
On Tue, 7 Apr 2020, Danh Doan wrote:
Show 17 quoted lines
> On 2020-04-07 06:54:33-0400, Derrick Stolee <stolee@gmail.com> wrote: > > On 4/6/2020 8:58 PM, Danh Doan wrote: > > > On 2020-04-06 10:42:23-0400, Derrick Stolee <stolee@gmail.com> wrote: > > >> Of course, not every platform has "cron" but that just means we need a > > >> cross-platform way to launch Git processes on some schedule. That could > > >> be a command that creates a cron job on platforms that have it, and on > > > > > > There's Unix system that doesn't have cron. > > > People could use other scheduler mechanism. > > > > > > A lot of systemd users uses systemd-timer. > > > I'm using snooze. > > > > Thanks for listing some alternatives. I'll look into these. > > I didn't mean to list those alternatives as only possible > alternatives.
In contrast, I think that they are _really_ alternatives, and they are only options for people who are dedicated fans of fiddling with the technical details.
In other words, `cron` is a very viable option for a few people who are _not_ in the audience of this here patch series.
The audience of this patch series are software engineers who _have_ to use Git, but do not really want to spend their time learning about the internal details. For those developers, especially those working on insanely large repositories, we want to provide some convenient functions (much like `git gc --auto` tries to help developers who do not want to bother with Git details, but _better_ because it tries very much to stay _out_ of the way of the developer, which `git gc --auto` distinctly does _not_) that were developed using the experience with the world's largest repository.
> The point is people have their own preference to choose a scheduler > that suites their need.
And they can!
But again, this here patch series is obviously for those who do not want to tinker with Git's functionality, yet still want to have decent performance.
Learning from the experience that led to the invention of `git gc --auto`, there is _a large_ benefit in doing this: `git gc --auto` was invented because some prolific Linux contributors were experiencing abysmal performance because they did not want to spend time learning how to keep their repositories in a good shape, but rather they wanted to spend time developing Linux kernel code.
Show 9 quoted lines
> Someone could use their own supervisor system with things like: > > #/bin/sh > > sleep 3600 # 1 hour > exec git cmd > > When "git cmd" exit, the supervisor will start the job again (because > it's down and it needs to be run).
Sure. And that would work for developers who are interested in how the world works, and have enough time to learn about this.
In my experience the vast majority of enterprise software developers are not really as excited about Git internals as I am. This patch series is for them. Because they are good people, too, and deserve our care in supporting them.
Ciao, Dscho