git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Finn Bryant <finnbryant@gmail.com>
To: git@vger.kernel.org
Subject: Sparse checkout inconsistency with non-folder paths between cone mode and full matching (2.5.0)
Date: Thu, 30 Jan 2020 15:25:56 +0000	[thread overview]
Message-ID: <CADSBhNbbO=aq-Oo2MpzDMN2VAX4m6f9Jb-eCtVVX1NfWKE9zJw@mail.gmail.com> (raw)

Hi,

With cone mode enabled for a sparse checkout, a pattern like the
following is accepted:

/*
!/*/
/a_file_or_folder/

As the name suggests, a_file_or_folder might be a file, or might be a
directory. If it's a directory, then this is a "valid" recursive match
for the directory and everything works as expected.
But if the path leads to an ordinary file, it appears that cone mode
will *exclude* the file from the worktree (ie, it'll have the
skip-worktree flag set).
This seems bizarre and unexpected behaviour.

My suspicion is that cone mode is supposed to be a pure subset of full
pattern matching, such that if cone mode is ever disabled, the
sparseness of the worktree will be unchanged. Clearly, this scenario
is breaking that pattern.

I think the correct behaviour is that recursive matches for a
potential directory do not have any effect on a non-directory file
with the same name. Alternatively, you could forbid any patterns which
match non-directory files instead (and downgrade to full pattern
matching), though I'd not be a fan of this, since it'd mean the
validity of a cone-mode sparse configuration file is dependent on the
contents of the repo, and is thus much harder to ascertain (scripts
can't simply prove if it's a valid cone mode file by parsing it,
they'd need to have access to any repo it may be applied to, and
inspect the type of any matching file/folder paths, and its validity
could be changed simply by replacing a folder with a file in the
repo).

If matching behaviour with full pattern mode is a non-goal for cone
mode, I'd still question the logic of this behaviour, though I suppose
it does have the benefit of (accidentally?) adding support for
excluding individual files from a sparse checkout, which I imagine
some could find useful. Personally I'd prefer that was instead added
with a more sane syntax, if needed.

Full test case:

$ git init test_repo
Initialized empty Git repository in [path]/test_repo/.git/
$ cd test_repo/
$ touch some_file a_file_or_folder
$ git add some_file a_file_or_folder
$ git commit -m "some files"
[master (root-commit) 80d5918] some files
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 a_file_or_folder
 create mode 100644 some_file
$ git sparse-checkout init --cone
$ git read-tree -mu HEAD
$ ls -1
a_file_or_folder
some_file
$ git sparse-checkout set a_file_or_folder
$ git read-tree -mu HEAD
$ ls -1
some_file
$ cat .git/info/sparse-checkout
/*
!/*/
/a_file_or_folder/
$


Right now I'm trying to integrate cone mode with my company's existing
manifest infrastructure, which doesn't differentiate between files and
folders, so this is forcing me to perform a lot of repo checks to
confirm we aren't accidentally excluding files we were supposed to
include. Just in case you needed another example of why this behaviour
is unhelpful.

             reply	other threads:[~2020-01-30 15:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-30 15:25 Finn Bryant [this message]
2020-01-30 18:52 ` Sparse checkout inconsistency with non-folder paths between cone mode and full matching (2.5.0) Derrick Stolee
2020-01-30 19:22   ` Derrick Stolee
2020-01-31 15:13   ` Finn Bryant
2020-01-31 19:59   ` Elijah Newren

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

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

  git send-email \
    --in-reply-to='CADSBhNbbO=aq-Oo2MpzDMN2VAX4m6f9Jb-eCtVVX1NfWKE9zJw@mail.gmail.com' \
    --to=finnbryant@gmail.com \
    --cc=git@vger.kernel.org \
    /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.
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 NNTP newsgroup(s).