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
> > >
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
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
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 migh
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 st
>> 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 rea
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 it
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 mis
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 b
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 instead
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 despi
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 status" inside them. Surely we w
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 avoid taking any
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 submodules already at
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 so
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
> > comm
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 opera
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 give
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
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 "
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, without having to lear
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 ans
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 same treatment t
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 r
24 matches
Mail list logo
