From: Victoria Dye <vdye@github.com>
To: Martin von Zweigbergk <martinvonz@google.com>
Cc: Glen Choo <chooglen@google.com>,
git@vger.kernel.org, Derrick Stolee <derrickstolee@github.com>,
Elijah Newren <newren@gmail.com>
Subject: Re: Bug report: `git restore --source --staged` deals poorly with sparse-checkout
Date: Wed, 5 Oct 2022 09:11:06 -0700 [thread overview]
Message-ID: <85def494-46c5-3785-8c78-31a733ab72e0@github.com> (raw)
In-Reply-To: <CAESOdVByucFm=yJn2yL1mwKGqey7tHXH4A-JM-yP125Ok+_Q+g@mail.gmail.com>
Martin von Zweigbergk wrote:>>>> Theoretically, 'restore' (like 'checkout') should be limited to pathspecs
>>>> inside the sparse-checkout patterns (per the documentation of
>>>> '--ignore-skip-worktree-bits'), but 'Documentation' does not match them.
>>>> Then, there's a difference between 'restore' and 'checkout' that doesn't
>>>> seem intentional; both remove the 'SKIP_WORKTREE' flag from the file, but
>>>> only 'checkout' creates the file on-disk (therefore avoiding the "deleted"
>>>> status).
>>>
>>> Restoring only into the index (as I think `git restore --staged` is supposed
>>> to do) is weird.
>>
>> 'git restore --staged' is intended to restore to both the worktree and index
>> (per 183fb44fd2 (restore: add --worktree and --staged, 2019-04-25)). The bug
>> you've identified is that it's not restoring to the worktree.
>
> Ah, `--worktree` is on by default even if I pass `--staged`, I see. Hmm, the
> help text actually says "Specifying --staged will only restore the index."...
You (and Elijah [1]) are correct. '--staged' overrides the "checkout to
worktree" default behavior of 'git restore' to only restore to the index. If
you want to checkout to the worktree _and_ the index, 'git restore --staged
--worktree' is what you'd use.
Sorry for the incorrect information!
[1] https://lore.kernel.org/git/CABPp-BGeC3hXw-v3voniY5ZU2f6W8NXfXVvq0C03eGGhvSefgg@mail.gmail.com/
next prev parent reply other threads:[~2022-10-05 16:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-03 22:05 Bug report: `git restore --source --staged` deals poorly with sparse-checkout Glen Choo
2022-10-04 16:34 ` Victoria Dye
[not found] ` <CAESOdVAh68HoQoyicfZn4XbjGfiRFCu1zFQmUjMcSAg3tUzr4Q@mail.gmail.com>
2022-10-04 20:34 ` Victoria Dye
2022-10-05 4:53 ` Martin von Zweigbergk
2022-10-05 7:51 ` Elijah Newren
2022-10-05 20:00 ` Martin von Zweigbergk
2022-10-06 4:20 ` Elijah Newren
2022-10-05 16:11 ` Victoria Dye [this message]
2022-10-05 5:22 ` Elijah Newren
2022-10-06 19:30 ` Junio C Hamano
2022-10-06 19:38 ` Junio C Hamano
2022-10-05 5:00 ` 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=85def494-46c5-3785-8c78-31a733ab72e0@github.com \
--to=vdye@github.com \
--cc=chooglen@google.com \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=martinvonz@google.com \
--cc=newren@gmail.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.
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).