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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 9/22/2017 12:25 AM, Jeff King wrote:
On Thu, Sep 21, 2017 at 08:25:50PM +0200, Johannes Sixt wrote:

+`GIT_OPTIONAL_LOCKS`::
+	If set to `0`, Git will avoid performing any operations which
+	require taking a lock and which are not required to complete the
+	requested operation. For example, this will prevent `git status`
+	from refreshing the index as a side effect. This is useful for
+	processes running in the background which do not want to cause
+	lock contention with other operations on the repository.
+	Defaults to `1`. >>
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.

We added '--no-lock-index' to keep status from locking the index
during status and effectively being read-only.  This helped with
problems with Visual Studio similar to the ones being described
for KDevelop.

Jeff




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux