From: <rsbecker@nexbridge.com>
To: <git@vger.kernel.org>
Subject: RE: [Possible Bug] sparse-checkout disable followed by re-init
Date: Mon, 7 Feb 2022 05:04:08 -0500 [thread overview]
Message-ID: <047a01d81c0a$0f12a340$2d37e9c0$@nexbridge.com> (raw)
In-Reply-To:
> -----Original Message-----
> From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
> Sent: February 7, 2022 4:57 AM
> To: git@vger.kernel.org
> Subject: [Possible Bug] sparse-checkout disable followed by re-init
>
> Hi All,
>
> I noticed a change at 2.35.1 regarding sparse-checkout and am wondering
> whether I am just missing something:
>
> 1. Create upstream.
> 2. Clone with --no-checkout --depth=1 --filter=blob:none 3.
sparse-checkout init
> 4. sparse-checkout set, with a pattern 5. sparse-checkout list 6. checkout
master
> 7. sparse-checkout reapply 8. sparse-checkout add (up to here, everything
is fine,
> the working area is consistent with the sparsity patterns) 9.
sparse-checkout
> disable (the disable works - I think) 10. sparse-checkout list reports
fatal: this
> worktree is not sparse, which is new in 2.35.1. In 2.34.1, the sparse
patterns are
> reported without error. I think this is incorrect behaviour because the
sparse
> patterns are still configured.
> Then I try to recover
> 11. sparse-checkout init (seems to work - no errors) 12. sparse-checkout
list
> (correctly reports what was previously set/add) 13. sparse-checkout
reapply
> (does nothing apparent - the objects that added to the working area during
the
> disable are still there. My assumption was that the files not matching the
sparsity
> patterns would be pruned).
>
> The .git/config is:
> [core]
> repositoryformatversion = 1
> filemode = true
> bare = false
> logallrefupdates = true
> [remote "origin"]
> url = file:///home/randall/stuff/src.git
> fetch = +refs/heads/master:refs/remotes/origin/master
> promisor = true
> partialclonefilter = blob:none
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> [extensions]
> worktreeConfig = true
>
> My question is, from this point, is there a way to recover the sparsity of
the
> working index (which I expect), or do I have to clone again (not
desirable). This
> seems like a functional change. What is weird to me is that I did not
expect a
> worktreeConfig=true in this situation.
>
> Thanks,
> Randall
Apologies for the wrapping. Outlook. Argh.
next reply other threads:[~2022-02-07 10:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-07 10:04 rsbecker [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-02-07 9:57 [Possible Bug] sparse-checkout disable followed by re-init rsbecker
2022-02-09 3:22 ` 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='047a01d81c0a$0f12a340$2d37e9c0$@nexbridge.com' \
--to=rsbecker@nexbridge.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).