Re: [PATCH v4] sparse-checkout.txt: new document with sparse-checkout directions

From: Elijah Newren <newren@gmail.com>
Date: Jan 24, 2023, 03:17 UTC
Message-ID: <CABPp-BGw2O5o1Erbih3a=cgk_H3=taYwpn5Mpedbx=HB1yxUfw@mail.gmail.com>
In-Reply-To: <CAOLTT8S3qaA7E0=qMHOKKs7F3zcNeXnscL-VrP3pVSHmxc7YZw@mail.gmail.com>

On Mon, Jan 23, 2023 at 7:05 AM ZheNing Hu <adlternative@gmail.com> wrote:

>
> Elijah Newren <newren@gmail.com> 于2023年1月20日周五 12:30写道：
> >
> > On Sat, Jan 14, 2023 at 2:19 AM ZheNing Hu <adlternative@gmail.com> wrote:

[...]

Show 13 quoted lines

> > > 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?

I wouldn't classify it as a problem. But, cone mode technically can experience the same behavior too, it's just that it should be fairly rare. That's because...

In a working tree, if an entire directory is missing, then obviously there are no files inside that directory. If there are no files, then there cannot be any untracked files. Since there are no untracked files within that directory, we do not need to find out which of those 0 files within that directory are ignored. Therefore, we do not need the .gitignore file(s) underneath that missing directory. Since in cone mode you only have the entire directory or none of it, whenever we are missing a .gitignore file, it is because we are missing the whole directory and the entire directory will be missing from the worktree too. So, we simply don't typically need the .gitignore files outside the sparse patterns.

If the directory is present, though, then you do need the .gitignore files so that you can classify untracked files within that directory into ignored and non-ignored categories.

Since non-cone mode tends to leave the directory around and have some files in it, you are going to need the .gitignore files for `git status` to correctly operate. That seems to me to be pretty intrinsic to that mode.

Now, cone mode can also experience this behavior by having a directory present in the worktree which is normally meant to be missing. This could happen due to the user manually creating the directory, or could be done by git if e.g. there are conflicts in directories outside the sparse cone when merging/rebasing/etc. Either of those cases would be rare, but in such a case we would need to download the .gitignore files within those directories as well. But, again, that'd make sense because we want to know which untracked files in the present directory are ignored when we run `git status`, so we need the .gitignore files.

Show 12 quoted lines

> > 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.

I don't consider it a bug. However, you have some statements below which appear contradictory to me, which may suggest that I'm misunderstanding what you are saying or misunderstanding the project setup you have.

Show 5 quoted lines

> >   * 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.

Why are you calling them unnecessary? Aren't they required for correct operation of `git status`?

> >   * Set status.showUntrackedFiles to `no` so that .gitignore files are
> > irrelevant
>
> This may also be a temporary rather than a complete solution.

How so? Do you expect users to override this option? If so, isn't that because they are interested in untracked files and likely want to know which ones are not ignored? And if so, isn't it then fine that we download the .gitignore files needed to answer their questions?

Show 5 quoted lines

> >   * 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.

I understand that restructuring a repository might not be enticing for a variety of reasons, and sometimes is just flat impossible. That may well be the case for you, but I just want to point out that your reason for not choosing this option seems to suggest you didn't understand the choice as I worded it, because:

Using cone mode does not necessarily imply more files, once you allow for restructuring the repository. If you restructure your repository such that the files you don't want in your sparse-checkout are in a separate directory, and you then use cone mode to select directories other than the ones with files you want excluded, then cone mode would give you the exact same selection of files as non-cone mode.

[...]

> >   * Remove the .gitignore files and commit their deletion.  Just do
> > without them, somehow.
>
> That's not a proper solution absolutely.

Why not? Above you called the .gitignore files "unnecessary". If they are unnecessary, then surely you can just get rid of them?

The point of the .gitignore files is to allow git to classify untracked files as either ignored or not. If classifying untracked files as ignored-or-not is important to you, then `git status` needs to download these files in order to do that classifying whenever there are any untracked files. So, the question for you is whether this classifying is necessary. If it's not necessary, then just delete the files since they serve no other purpose. If it is necessary, then why complain that they are downloaded?