Elijah Newren <newren@xxxxxxxxx> 于2023年1月20日周五 12:30写道： > > On Sat, Jan 14, 2023 at 2:19 AM ZheNing Hu <adlternative@xxxxxxxxx> wrote: > > > > Elijah Newren <newren@xxxxxxxxx> 于2022年11月16日周三 13:49写道： > > > > > [...] > > > > > + The fact that files can move between the 'tracked' and 'untracked' > > > > > + categories means some commands will have to treat untracked files > > > > > + differently. But if we have to treat untracked files differently, > > > > > + then additional commands may also need changes: > > > > > + > > > > > + * status > > > > > + * clean > > > > > + > > > > > > > > I'm a bit worried about git status, because it's used in many shells > > > > (e.g. zsh) i > > > > in the git prompt function. Its default behavior is restricted, otherwise users > > > > may get blocked when they use zsh to cd to that directory. I don't know how > > > > to reproduce this problem (since the scenario is built on checkout to a local > > > > unborn branch). > > > > > > Could you elaborate? I'm not sure if you are talking about an > > > existing problem that you are worried about being exacerbated, or a > > > hypothetical problem that could occur with changes. Further, your > > > wording is so vague about the problem, that I have no idea what its > > > nature is or whether any changes to status would even possibly have > > > any bearing on it. But the suggested changes to git status are > > > simply: > > > > > > > I find this special case, it will fetch some blobs when "git status". > > First, we init a git repository, then set sparse specification to "*.js" with > > no-cone mode, then use blob:none filter to fetch all commits and trees, > > and finally checkout to the default branch. > > > > #!/bin/sh > > > > rm -rf sparse-checkout-example > > git init sparse-checkout-example > > git -C sparse-checkout-example remote add origin > > git@xxxxxxxxxx:derrickstolee/sparse-checkout-example.git > > git -C sparse-checkout-example sparse-checkout set --no-cone *.js > > git -C sparse-checkout-example fetch origin --filter=blob:none main > > git -C sparse-checkout-example branch --track main origin/main > > git -C sparse-checkout-example checkout main > > > > Then let's do a git status, which some zsh git plugin > > will do when user "cd" the git repository. > > > > # git -C sparse-checkout-exmaple status > > > > remote: Enumerating objects: 1, done. > > remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 1 > > Receiving objects: 100% (1/1), 416 bytes | 416.00 KiB/s, done. > > remote: Enumerating objects: 1, done. > > remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 1 > > Receiving objects: 100% (1/1), 160 bytes | 160.00 KiB/s, done. > > remote: Enumerating objects: 1, done. > > remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 1 > > Receiving objects: 100% (1/1), 2.01 KiB | 2.01 MiB/s, done. > > remote: Enumerating objects: 1, done. > > remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 1 > > Receiving objects: 100% (1/1), 120 bytes | 120.00 KiB/s, done. > > On branch main > > Your branch is up to date with 'origin/main'. > > > > You are in a sparse checkout with 8% of tracked files present. > > > > > > It took 17.00 seconds to enumerate untracked files. 'status -uno' > > may speed it up, but you have to be careful not to forget to add > > new files yourself (see 'git help status'). > > nothing to commit, working tree clean > > > > Yeah, here it fetches four blobs, and takes 17s!!! > > > > So what blobs are we fetching? > > > > GIT_TRACE_PACKET=1 git -C sparse-checkout-example status > > ... > > 18:02:32.989231 pkt-line.c:80 packet: fetch> want > > dff85a65c0ef4b50a4c01bdd4a247b974bc45f90 > > ... > > 18:02:37.059203 pkt-line.c:80 packet: fetch> want > > f07ead02d13f62414589b1f1b891bb6a764ec91f > > ... > > 18:02:40.868899 pkt-line.c:80 packet: fetch> want > > 3c4efe206bd0e7230ad0ae8396a3c883c8207906 > > ... > > 18:02:44.961809 pkt-line.c:80 packet: fetch> want > > 6590681af7e177dc71fe08648c4bbf4223b82866 > > > > > > Then let's we look what's the blob: > > git log --find-object=dff85a65c0ef4b50a4c01bdd4a247b974bc45f90 --stat > > commit 8ec229339caad56eb849c67361a9699004564177 > > Author: Derrick Stolee <dstolee@xxxxxxxxxxxxx> > > Date: Mon Dec 30 13:30:27 2019 -0500 > > > > Add twbs/bootstrap > > > > web/browser/.gitignore | 47 +++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 47 insertions(+) > > > > git log --find-object=f07ead02d13f62414589b1f1b891bb6a764ec91f --stat > > commit 9c5a31030de62355410a322923e33e90a00032f6 > > Author: Derrick Stolee <dstolee@xxxxxxxxxxxxx> > > Date: Mon Dec 30 13:31:06 2019 -0500 > > > > Add artsy/artsy.github.io > > > > web/editor/.gitignore | 13 +++++++++++++ > > 1 file changed, 13 insertions(+) > > > > Yeah, it seems that git status fetch these .gitigore files. > > So what's the wrong here? > > Nothing; this looks exactly as I'd expect. > > `git status` is supposed to check whether untracked files are ignored > or not, and it needs .gitignore files to do so. If an entire > directory is missing, then it can avoid loading a .gitignore under > that directory, but you set up your patterns such that no directory is > likely to be excluded. > This may be a bit strange, why doesn't the cone mode have this problem? > Maybe there are other special cases that one could attempt to handle > (e.g. first check if there are any untracked files in a directory and > only then check for which are ignored, but that'd probably take some > big refactoring of some hairy dir.c code to accomplish something like > that, and you'd have to be really careful to not regress the > performance of non-sparse cases). Personally, I don't think it's > worth it. If you really don't like it, I'd suggest choosing any one > of the following ways to avoid it: > This "bug" may not be very important, because it has no application at present, scalar also uses cone mode by default. > * Include the .gitignore files in your sparse-checkout; might as > well since you're going to get them anyway. This can also seem like a pain in the butt because of the extra unnecessary .gitigore downloads. > * Set status.showUntrackedFiles to `no` so that .gitignore files are > irrelevant This may also be a temporary rather than a complete solution. > * Use cone mode instead of non-cone mode (and yes, restructure your > repo if needed) No, I might think cone mode has some other disadvantages: it includes too many files. I would prefer to get the behavior of non-cone mode. > * Remove the .gitignore files and commit their deletion. Just do > without them, somehow. That's not a proper solution absolutely. Anyway, thanks for the answer! -- ZheNing Hu
