git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Elijah Newren <newren@gmail.com>
To: ZheNing Hu <adlternative@gmail.com>
Cc: Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Victoria Dye <vdye@github.com>,
	Derrick Stolee <derrickstolee@github.com>,
	Shaoxuan Yuan <shaoxuan.yuan02@gmail.com>,
	Matheus Tavares <matheus.bernardino@usp.br>,
	Glen Choo <chooglen@google.com>,
	Martin von Zweigbergk <martinvonz@google.com>
Subject: Re: [PATCH v4] sparse-checkout.txt: new document with sparse-checkout directions
Date: Mon, 23 Jan 2023 19:17:00 -0800	[thread overview]
Message-ID: <CABPp-BGw2O5o1Erbih3a=cgk_H3=taYwpn5Mpedbx=HB1yxUfw@mail.gmail.com> (raw)
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:
[...]
> > > 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.

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

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

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

      reply	other threads:[~2023-01-24  3:18 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-25  0:09 [PATCH] sparse-checkout.txt: new document with sparse-checkout directions Elijah Newren via GitGitGadget
2022-09-26 17:20 ` Junio C Hamano
2022-09-26 17:38 ` Junio C Hamano
2022-09-27  3:05   ` Elijah Newren
2022-09-27  4:30     ` Junio C Hamano
2022-09-26 20:08 ` Victoria Dye
2022-09-26 22:36   ` Junio C Hamano
2022-09-27  7:30     ` Elijah Newren
2022-09-27 16:07       ` Junio C Hamano
2022-09-28  6:13         ` Elijah Newren
2022-09-27  6:09   ` Elijah Newren
2022-09-27 16:42   ` Derrick Stolee
2022-09-28  5:42     ` Elijah Newren
2022-09-27 15:43 ` Junio C Hamano
2022-09-28  7:49   ` Elijah Newren
2022-09-27 16:36 ` Derrick Stolee
2022-09-28  5:38   ` Elijah Newren
2022-09-28 13:22     ` Derrick Stolee
2022-10-06  7:10       ` Elijah Newren
2022-10-06 18:27         ` Derrick Stolee
2022-10-07  2:56           ` Elijah Newren
2022-09-30  9:54     ` ZheNing Hu
2022-10-06  7:53       ` Elijah Newren
2022-10-15  2:17         ` ZheNing Hu
2022-10-15  4:37           ` Elijah Newren
2022-10-15 14:49             ` ZheNing Hu
2022-09-30  9:09   ` ZheNing Hu
2022-09-28  8:32 ` [PATCH v2] " Elijah Newren via GitGitGadget
2022-10-08 22:52   ` [PATCH v3] " Elijah Newren via GitGitGadget
2022-11-06  6:04     ` [PATCH v4] " Elijah Newren via GitGitGadget
2022-11-07 20:44       ` Derrick Stolee
2022-11-16  4:39         ` Elijah Newren
2022-11-15  4:03       ` ZheNing Hu
2022-11-16  3:18         ` ZheNing Hu
2022-11-16  6:51           ` Elijah Newren
2022-11-16  5:49         ` Elijah Newren
2022-11-16 10:04           ` ZheNing Hu
2022-11-16 10:10             ` ZheNing Hu
2022-11-16 14:33               ` ZheNing Hu
2022-11-19  2:36                 ` Elijah Newren
2022-11-19  2:15             ` Elijah Newren
2022-11-23  9:08               ` ZheNing Hu
2023-01-14 10:18           ` ZheNing Hu
2023-01-20  4:30             ` Elijah Newren
2023-01-23 15:05               ` ZheNing Hu
2023-01-24  3:17                 ` Elijah Newren [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABPp-BGw2O5o1Erbih3a=cgk_H3=taYwpn5Mpedbx=HB1yxUfw@mail.gmail.com' \
    --to=newren@gmail.com \
    --cc=adlternative@gmail.com \
    --cc=chooglen@google.com \
    --cc=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=martinvonz@google.com \
    --cc=matheus.bernardino@usp.br \
    --cc=shaoxuan.yuan02@gmail.com \
    --cc=vdye@github.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).