Re: git status --ignored hangs when a deep directory structure present in working tree

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

 



On Mon, Jan 27, 2020 at 9:06 PM Elijah Newren <newren@xxxxxxxxx> wrote:
>
> On Mon, Jan 27, 2020 at 4:08 AM SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote:
> >
> > On Mon, Jan 27, 2020 at 11:55:01AM +0100, Martin Melka wrote:
> > > Hi all, I have ran across what might be a bug in git. When there is a
> > > deep directory structure (tried on 100+ nested dirs), then git status
> > > --ignored hangs indefinitely.
> > > Discovered this on OSX (Mojave, git 2.20.1 (Apple Git-117)), but it
> > > reproduces in Ubuntu (19.04, git 2.25.0) Docker container on OSX and
> > > also on baremetal Ubuntu server (16.04, git 2.17.1).
> > >
> > > Steps to reproduce:
> > >
> > > 1. Generate the deep dir structure:
> > >
> > >     mkdir gittest; pushd gittest; git init; for i in $(seq 1 120); do
> > > mkdir dir; cd dir; done; touch leaf; popd
> > >
> > > 2. Try to get git status --ignored
> > >
> > >     cd gittest && git status --ignored
> > >
> > >
> > > If there is a dir depth limit, git should probably exit with an error
> > > rather than getting stuck endlessly.
> >
> > This is interesting, thanks for the report.
>
> Agreed.
>
> > There is no such directory depth limit, but the runtime of 'git status
> > --ignored' grows quickly with the depth of the untracked directory.
> > Running this shell loop produces the numbers below:
> >
> > for depth in $(seq 10 30)
> > do
> >         dirs=$(for i in $(seq 1 $depth) ; do printf 'dir/' ; done)
> >         rm -rf dir
> >         mkdir -p $dirs
> >         >$dirs/untracked-file
> >         /usr/bin/time --format="$depth: %e" git status --ignored >/dev/null
> > done
> >
> > 10: 0.01
> > 11: 0.03
> > 12: 0.05
> > 13: 0.11
> > 14: 0.23
> > 15: 0.47
> > 16: 0.97
> > 17: 1.97
> > 18: 3.88
> > 19: 7.85
> > 20: 16.29
> > 21: 32.92
> > 22: 76.24
>
> Wow.
>
> Really nice testcase, though, thanks.
>
[...]
> We'll see
> if my patch goes anywhere, or if it's just another dead-end among
> many.

Since gitgitgadget doesn't have an in-reply-to capability, for those
wanting to follow along see
https://lore.kernel.org/git/pull.700.git.git.1580335424.gitgitgadget@xxxxxxxxx/




[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