Thread (20 messages) flat view 20 messages, 7 authors, 2017-09-28

Re: [PATCH] git: add --no-optional-locks option

From: Jeff King <hidden>
Date: 2017-09-22 15:04:46

On Fri, Sep 22, 2017 at 07:22:28AM -0400, Jeff Hostetler wrote:
quoted
quoted
I don't think we should pass this environment variable to remote
repositories. It should be listed in local_repo_env[] in environment.c.
I'm not sure I agree. This is really about the context in which the
command is executing, not anything about the particular repository
you're operating on.

For fetch/push operations that touch a remote, I doubt it would matter
either way (and anyway, those often cross network boundaries that don't
propagate environment variables anyway).

But imagine that "git status" learns to recurse into submodules and run
"git status" inside them. Surely we would want the submodule repos to
also avoid taking any unnecessary locks?

-Peff
https://github.com/git-for-windows/git/commit/ff63b51c22389139a864eb2e565c6cdc5a30f061

https://github.com/git-for-windows/git/pull/1004/commits/45bad66192352481acbc826f11d90c8928b39a7a

We should compare this with what we did in Git for Windows last fall.
I guess those commits didn't get pushed upstream.
Right. I think you missed the initial message in the thread that
explains how this is an expanded version of ff63b51c22. :)

I didn't know about the environment thing in 45bad66192, though[1]. That
makes me even more confident that this is the right approach.

-Peff

[1] Sorry for not doing my homework more carefully on the existing
    solution.  GitHub Desktop ran into the same situation and pointed me
    at ff63b51c22. I extrapolated the rest of it on my own. ;)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help