On Fri, May 3, 2019 at 4:47 PM Johannes Schindelin
wrote:
>
> Hi Duy,
>
> On Fri, 3 May 2019, Duy Nguyen wrote:
>
> > I have a feeling that most operations read the index unlocked,
> > manipulate and only lock before writing things out. So yeah it's
> > probably already racy.
>
> IIRC there is a c
Hi Duy,
On Fri, 3 May 2019, Duy Nguyen wrote:
> I have a feeling that most operations read the index unlocked,
> manipulate and only lock before writing things out. So yeah it's
> probably already racy.
IIRC there is a check for that, so it is not actually racy ;-)
Ciao,
Johannes
On Thu, May 2, 2019 at 11:58 PM Jeff King wrote:
> > I might take a stab at the "wait and try to hold the lock again, doing
> > necessary verification after if needed" idea. It sounds like the right
> > way to go and we haven't had problems with refs doing the same thing
> > (have we?).
>
> No, bu
On Thu, May 2, 2019 at 11:58 PM Jeff King wrote:
> > I might take a stab at the "wait and try to hold the lock again, doing
> > necessary verification after if needed" idea. It sounds like the right
> > way to go and we haven't had problems with refs doing the same thing
> > (have we?).
>
> No, bu
On Thu, May 02, 2019 at 11:38:51PM +0700, Duy Nguyen wrote:
> > Since the decision of whether to use the locks is dependent on the
> > operation being performed, it's an environment variable and not a config
> > option.
>
> And there's also tradeoff for doing it. If git-status will not take
> loc
On Thu, May 2, 2019 at 10:07 PM Jeff King wrote:
>
> On Thu, May 02, 2019 at 04:45:36PM +0300, Aleksey Midenkov wrote:
>
> > > Assuming that kdevelop is just running "git status" in the background,
> > > though, there's an easier solution. If it uses "git --no-optional-locks
> > > status" instead,
On Thu, May 02, 2019 at 04:45:36PM +0300, Aleksey Midenkov wrote:
> > Assuming that kdevelop is just running "git status" in the background,
> > though, there's an easier solution. If it uses "git --no-optional-locks
> > status" instead, that will instruct it not to take the index lock at
> > all.
On Wed, May 1, 2019 at 9:36 PM Jeff King wrote:
>
> On Wed, May 01, 2019 at 10:15:19AM +0300, Aleksey Midenkov wrote:
>
> > > Usually when we see racy contention on index.lock, the culprit turns out
> > > to be another unrelated git process refreshing the index. Do you have
> > > anything else run
On Wed, May 01, 2019 at 10:15:19AM +0300, Aleksey Midenkov wrote:
> > Usually when we see racy contention on index.lock, the culprit turns out
> > to be another unrelated git process refreshing the index. Do you have
> > anything else running which might be using "git status" (e.g., magit in
> > e
On Tue, Apr 30, 2019 at 8:41 PM Jeff King wrote:
>
> On Tue, Apr 30, 2019 at 02:19:11PM +0300, Aleksey Midenkov wrote:
>
> > > I gave it about 2000 commits (from v2.20.1 to master on git.git) to
> > > rebase. No luck.
> >
> > Please, try on this repo: g...@github.com:tempesta-tech/mariadb
> >
> >
On Tue, Apr 30, 2019 at 02:19:11PM +0300, Aleksey Midenkov wrote:
> > I gave it about 2000 commits (from v2.20.1 to master on git.git) to
> > rebase. No luck.
>
> Please, try on this repo: g...@github.com:tempesta-tech/mariadb
>
> ```
> git checkout 62a082f573
> git rebase -p -x /tmp/check.sh ca
On Mon, Apr 29, 2019 at 2:35 PM Duy Nguyen wrote:
>
> On Mon, Apr 29, 2019 at 6:03 PM Aleksey Midenkov wrote:
> >
> > Reproduce:
> > ```
> > cat << EOF >> /tmp/check.sh
> > #!/bin/sh
> > git log HEAD~..HEAD | cat
> > # sleep 1
> > EOF
> > chmod +x /tmp/check.sh
> > git rebase -p -x /tmp/check.sh
Hi Aleksey,
On Mon, 29 Apr 2019, Aleksey Midenkov wrote:
> git rebase -p -x /tmp/check.sh base
> ```
> If the `base` is far away enough it fails with "fatal: Unable to
> create '.../.git/index.lock': File exists." at an arbitrary commit.
Does it work if you pass `-r` instead of `-p`? The latter
On Mon, Apr 29, 2019 at 6:03 PM Aleksey Midenkov wrote:
>
> Reproduce:
> ```
> cat << EOF >> /tmp/check.sh
> #!/bin/sh
> git log HEAD~..HEAD | cat
> # sleep 1
> EOF
> chmod +x /tmp/check.sh
> git rebase -p -x /tmp/check.sh base
> ```
> If the `base` is far away enough it fails with "fatal: Unable
Reproduce:
```
cat << EOF >> /tmp/check.sh
#!/bin/sh
git log HEAD~..HEAD | cat
# sleep 1
EOF
chmod +x /tmp/check.sh
git rebase -p -x /tmp/check.sh base
```
If the `base` is far away enough it fails with "fatal: Unable to
create '.../.git/index.lock': File exists." at an arbitrary commit.
Abort cur
15 matches
Mail list logo
