-
Notifications
You must be signed in to change notification settings - Fork 25.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fetch: support "--super-prefix" #1378
Conversation
There are issues in commit 8fa89f3: |
/submit |
There are issues in commit 8fa89f3: |
/submit |
There are issues in commit 8fa89f3: |
In a repo with partially cloned submodules, "git restore --recurse-submodules" from the superproject can fail with "fatal: fetch doesn't support --super-prefix". This error is encountered when the super prefix is set (either by passing "--super-prefix" or by setting the GIT_INTERNAL_SUPER_PREFIX env var) on a command that isn't marked SUPPORT_SUPER_PREFIX. In this case, "git restore --recurse-submodules" invokes "git read-tree --super-prefix=<path to submodule>", which in turn, invokes a "git fetch" to fetch promisor objects. The usefulness of this "--super-prefix" check is up for debate, and there is WIP to get rid of the option altogether [1], but we can't just leave "git restore" broken in the meantime, so let's do the barest minimum to fix this without causing too much trouble for that effort. Mark cmd_fetch as SUPPORT_SUPER_PREFIX, and add a test that shows that this fixes the bug described above. There is precedent for using SUPPORT_SUPER_PREFIX solely as a workaround for the super prefix check (c.f. [2]), which is all the more reason to get rid of this check. [1] https://lore.kernel.org/git/Y27D8QUl3I2d4xNe@nand.local/ [2] 53fcfbc (fsmonitor--daemon: allow --super-prefix argument, 2022-05-26) Suggested-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Glen Choo <chooglen@google.com>
8fa89f3
to
f5fc9b3
Compare
/submit |
Submitted as pull.1378.git.git.1668210935360.gitgitgadget@gmail.com To fetch this version into
To fetch this version to local tag
|
This patch series was integrated into seen via 8aea09d. |
This patch series was integrated into seen via b14083c. |
This patch series was integrated into seen via 757e337. |
This patch series was integrated into seen via c6f0c3f. |
This patch series was integrated into seen via 9b55b93. |
This patch series was integrated into seen via 2e67bb4. |
This patch series was integrated into seen via d35cf37. |
This patch series was integrated into seen via 32b854b. |
This patch series was integrated into seen via f4e4d70. |
This patch series was integrated into seen via 24b1c28. |
This patch series was integrated into seen via 686a452. |
This patch series was integrated into seen via aa45880. |
This patch series was integrated into seen via 9bbcd0a. |
This patch series was integrated into seen via dd11342. |
This patch series was integrated into seen via 190e753. |
This patch series was integrated into seen via 21b7d35. |
This patch series was integrated into seen via 3310284. |
This patch series was integrated into seen via c435771. |
This patch series was integrated into seen via 5194418. |
This patch series was integrated into seen via 1ec1c7f. |
This patch series was integrated into seen via 256eddc. |
This patch series was integrated into seen via 659b9dc. |
This patch series was integrated into seen via f59b2ef. |
This patch series was integrated into seen via c6f820a. |
This patch series was integrated into next via 126b1fb. |
This patch series was integrated into seen via 126b1fb. |
This patch series was integrated into seen via 8e4e48b. |
This patch series was integrated into seen via d4c5400. |
This patch series was integrated into master via d4c5400. |
This patch series was integrated into next via d4c5400. |
Closed via d4c5400. |
Since "git read-tree" is seriously broken at the moment, let's not keep
it hostage to the work on [1]. This is Ævar's suggested change from [2]
combined with my partial clone test case from [3].
I think we can take this regardless of where we are with the RFCs; it's
simple and obvious enough that it adds virtually no churn to the RFCs.
[1] https://lore.kernel.org/git/Y27D8QUl3I2d4xNe@nand.local/
[2] https://lore.kernel.org/git/221109.86y1skq08e.gmgdl@evledraar.gmail.com
[3] https://lore.kernel.org/git/20221109004708.97668-4-chooglen@google.com
Cc: Ævar Arnfjörð Bjarmason avarab@gmail.com