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

On Wed, Sep 27, 2017 at 07:20:05PM +0530, Kaartic Sivaraam wrote: > On Wed, 2017-09-27 at 02:40 -0400, Jeff King wrote: > > On Sun, Sep 24, 2017 at 01:08:41PM +0530, Kaartic Sivaraam wrote: > > > > > > > > So, if I get that correctly "git status --no-optional-locks" is a way to > > > get > > >

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

On Wed, 2017-09-27 at 02:40 -0400, Jeff King wrote: > On Sun, Sep 24, 2017 at 01:08:41PM +0530, Kaartic Sivaraam wrote: > > > > > So, if I get that correctly "git status --no-optional-locks" is a way to get > > the "current" status without updating the on disk index file? > > It's actually "git

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

On Mon, Sep 25, 2017 at 11:51:31AM -0700, Stefan Beller wrote: > > diff --git a/read-cache.c b/read-cache.c > > index 65f4fe8375..fc1ba122a3 100644 > > --- a/read-cache.c > > +++ b/read-cache.c > > @@ -1563,7 +1563,8 @@ static int read_index_extension(struct index_state > > *istate, > > > > int

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

On Sun, Sep 24, 2017 at 01:08:41PM +0530, Kaartic Sivaraam wrote: > On Thursday 21 September 2017 10:02 AM, Jeff King wrote: > > Some tools like IDEs or fancy editors may periodically run > > commands like "git status" in the background to keep track > > of the state of the repository. > > I

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

On 9/25/2017 12:17 PM, Johannes Schindelin wrote: Hi Kaartic, On Sun, 24 Sep 2017, Kaartic Sivaraam wrote: On Thursday 21 September 2017 10:02 AM, Jeff King wrote: Some tools like IDEs or fancy editors may periodically run commands like "git status" in the background to keep track of the

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

>> There might be another option to cope with the situation: >> >> 4. Teach all commands to spinlock / busywait shortly for important >> locks instead of giving up. In that case git-status rewriting >> the index ought to be fine? > > We do have all the infrastructure in place to do a

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

On Mon, Sep 25, 2017 at 06:10:12PM +0200, Johannes Schindelin wrote: > On Thu, 21 Sep 2017, Jeff King wrote: > > > Johannes, this is an adaptation of your 67e5ce7f63 (status: offer *not* > > to lock the index and update it, 2016-08-12). Folks working on GitHub > > Desktop complained to me that

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

Hi Kaartic, On Sun, 24 Sep 2017, Kaartic Sivaraam wrote: > On Thursday 21 September 2017 10:02 AM, Jeff King wrote: > > Some tools like IDEs or fancy editors may periodically run commands > > like "git status" in the background to keep track of the state of the > > repository. > > I might be

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

Hi Peff, On Thu, 21 Sep 2017, Jeff King wrote: > Johannes, this is an adaptation of your 67e5ce7f63 (status: offer *not* > to lock the index and update it, 2016-08-12). Folks working on GitHub > Desktop complained to me that it's only available on Windows. :) Okay, so this is trying to help me

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

On Thursday 21 September 2017 10:02 AM, Jeff King wrote: > Some tools like IDEs or fancy editors may periodically run > commands like "git status" in the background to keep track > of the state of the repository. I might be missing something, shouldn't the IDEs be encouraged to use libgit2

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

On Fri, Sep 22, 2017 at 02:41:06PM -0700, Stefan Beller wrote: > > Ah, thanks. I _thought_ we could already do that but when I went looking > > for the standard --recursive option I couldn't find it. > > Thanks for checking for submodules there. > > I personally prefer --recurse-submodules

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

On Fri, Sep 22, 2017 at 2:25 PM, Jeff King wrote: > On Fri, Sep 22, 2017 at 01:09:32PM -0700, Stefan Beller wrote: > >> On Thu, Sep 21, 2017 at 9:25 PM, Jeff King wrote: >> >> > >> > But imagine that "git status" learns to recurse into submodules and run >> > "git

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

On Fri, Sep 22, 2017 at 01:09:32PM -0700, Stefan Beller wrote: > On Thu, Sep 21, 2017 at 9:25 PM, Jeff King wrote: > > > > > 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

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

On Thu, Sep 21, 2017 at 9:25 PM, Jeff King wrote: > > 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? You can teach Git to recurse into

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

On Fri, Sep 22, 2017 at 01:42:10AM -0500, Daniel Santos wrote: > > But taking the index lock may conflict with other operations > > in the repository. Especially ones that the user is doing > > themselves, which _aren't_ opportunistic. In other words, > > "git status" knows how to back off when

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

On Fri, Sep 22, 2017 at 07:22:28AM -0400, Jeff Hostetler wrote: > > > 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 > >

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

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

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

On 09/20/2017 11:32 PM, Jeff King wrote: > Johannes, this is an adaptation of your 67e5ce7f63 (status: offer *not* > to lock the index and update it, 2016-08-12). Folks working on GitHub > Desktop complained to me that it's only available on Windows. :) > > I expanded the scope a bit to let us

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

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

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

Am 21.09.2017 um 06:32 schrieb Jeff King: diff --git a/Documentation/git.txt b/Documentation/git.txt index 6e3a6767e5..8dd3ae05ae 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -159,6 +159,10 @@ foo.bar= ...`) sets `foo.bar` to the empty string which ` git config Add

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

Jeff King writes: > I admit that's just adding more hand-waving to the pile. But I don't > think it really _hurts_ to leave that door open (aside from making the > documentation a bit wishy-washy). And it helps because callers would > pick up the new features automatically,

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

On Thu, Sep 21, 2017 at 01:55:58PM +0900, Junio C Hamano wrote: > The phrase 'optional lock' does not answer this question clearly, > though: does it make sense to extend the coverage of this option in > the future to things more than the "opportunistic update to the > index file"? > > If the

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

Jeff King writes: > Johannes, this is an adaptation of your 67e5ce7f63 (status: offer *not* > to lock the index and update it, 2016-08-12). Folks working on GitHub > Desktop complained to me that it's only available on Windows. :) > > I expanded the scope a bit to let us give the

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

Johannes, this is an adaptation of your 67e5ce7f63 (status: offer *not* to lock the index and update it, 2016-08-12). Folks working on GitHub Desktop complained to me that it's only available on Windows. :) I expanded the scope a bit to let us give the same treatment to more commands in the long