Fredrik Gustafsson wrote:
> If core.preload is set to a non-zero value, every time a git command is
> executed, git status will be runned in the background if the value of
> core.preload is lower than the number of seconds since last run.
Counting the number of seconds since the last run is gross. This kind
of setting makes sense in the credential-helper, where you specify how
long to cache your password. I don't think you should use a
time-based trigger for this feature.
> Please see this thread:
> This solution solves many of the problems discussed there, but
> introduces new ones. For example, it does have a bigger impact.
> With this solution beeing functional but a bit gross, it's not sure that
> it should be placed here at all. However, it's a good place to place it
> for all git-tools to be able to use it without knowing about it. (It
> would speed up all git wrappers and not just bash-prompt like the
> previous solution).
Yes, but you're proposing including a very gross feature in core git.
I'm sorry, but this is a non-starter.
> There's a few more things to address before shipping this if this is
> considered a good approach. Such as:
> * Don't run if a "git status"-like git command has been runned. Or a
> non-repo git command (lite git status or git help) is runned.
> * Better names for settings and files.
> * Better(?) invokation of git status (a forked internal call instead
> of a system call?).
> Signed-off-by: Fredrik Gustafsson <iv...@iveqy.com>
> git.c | 30 ++++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
I would argue that git.c is the wrong place to implement this feature.
You're essentially doing fopen(), fclose(), stat(), and system():
shouldn't this be a shell script? I earlier suggested making it
something we can hook to chpwd() in zsh, and I think this is the most
sane suggestion. This is what z()  uses, and I would argue that
your feature shares many similarities with it.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html