From: Kache Hit <hidden> Date: 2022-07-19 21:36:52
Hi. Output of git bugreport:
---
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
Wanted to retain git tree structure when pulling latest and rebasing.
First indication of error was the `rebase -r` of the merge commit
What did you expect to happen? (Expected behavior)
successful --rebase-merges rebase of my commits on top of master
What happened instead? (Actual behavior)
What's different between what you expected and what actually happened?
Anything else you want to add:
I'm currently "stuck" in this state, not sure how to recover or repro:
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.37.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Tue Feb 22 21:10:41
PST 2022; root:xnu-7195.141.26~1/RELEASE_X86_64 x86_64
compiler info: clang: 13.0.0 (clang-1300.0.29.30)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]
pre-commit
pre-push
From: Kache Hit <hidden> Date: 2022-07-19 22:20:25
A thought: the 179457 is reminiscent of something else I did just before this:
I was doing some "code archeology" and was headlessly checking out
some old SHAs in this large monorepo.
During checkout, it said it was updating 174823 files in total.
On Tue, Jul 19, 2022 at 2:36 PM Kache Hit [off-list ref] wrote:
Hi. Output of git bugreport:
---
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
Wanted to retain git tree structure when pulling latest and rebasing.
First indication of error was the `rebase -r` of the merge commit
What did you expect to happen? (Expected behavior)
successful --rebase-merges rebase of my commits on top of master
What happened instead? (Actual behavior)
What's different between what you expected and what actually happened?
Anything else you want to add:
I'm currently "stuck" in this state, not sure how to recover or repro:
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.37.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Tue Feb 22 21:10:41
PST 2022; root:xnu-7195.141.26~1/RELEASE_X86_64 x86_64
compiler info: clang: 13.0.0 (clang-1300.0.29.30)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]
pre-commit
pre-push
From: Johannes Schindelin <hidden> Date: 2022-07-29 16:00:02
Hi Kache,
On Tue, 19 Jul 2022, Kache Hit wrote:
A thought: the 179457 is reminiscent of something else I did just before this:
I was doing some "code archeology" and was headlessly checking out
some old SHAs in this large monorepo.
During checkout, it said it was updating 174823 files in total.
Do you think it would be possible to whittle this down a bit, and maybe
attempt to come up with a reproducible example? Something like what is
described in https://stackoverflow.com/help/mcve.
If all else fails, and you _only_ manage to reproduce it in the original
repository, could you at least try to figure out a reliable way to get the
Git index into the indicated state (if I were you, I would start off by
switching to the pre-rebase revision, deleting `.git/index` and then
running `git reset --hard` and then see whether the bug can be
reproduced)?
Ciao,
Johannes
On Tue, Jul 19, 2022 at 2:36 PM Kache Hit [off-list ref] wrote:
quoted
Hi. Output of git bugreport:
---
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
Wanted to retain git tree structure when pulling latest and rebasing.
First indication of error was the `rebase -r` of the merge commit
What did you expect to happen? (Expected behavior)
successful --rebase-merges rebase of my commits on top of master
What happened instead? (Actual behavior)
What's different between what you expected and what actually happened?
Anything else you want to add:
I'm currently "stuck" in this state, not sure how to recover or repro:
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.37.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Tue Feb 22 21:10:41
PST 2022; root:xnu-7195.141.26~1/RELEASE_X86_64 x86_64
compiler info: clang: 13.0.0 (clang-1300.0.29.30)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]
pre-commit
pre-push
From: Kache Hit <hidden> Date: 2022-08-23 04:54:16
Hi,
I've not been able to successfully repro this after managing to
recover from it by rebuilding the index:
https://stackoverflow.com/questions/73044253
I'm sorry I couldn't be more helpful.
On Fri, Jul 29, 2022 at 8:59 AM Johannes Schindelin
[off-list ref] wrote:
Hi Kache,
On Tue, 19 Jul 2022, Kache Hit wrote:
quoted
A thought: the 179457 is reminiscent of something else I did just before this:
I was doing some "code archeology" and was headlessly checking out
some old SHAs in this large monorepo.
During checkout, it said it was updating 174823 files in total.
Do you think it would be possible to whittle this down a bit, and maybe
attempt to come up with a reproducible example? Something like what is
described in https://stackoverflow.com/help/mcve.
If all else fails, and you _only_ manage to reproduce it in the original
repository, could you at least try to figure out a reliable way to get the
Git index into the indicated state (if I were you, I would start off by
switching to the pre-rebase revision, deleting `.git/index` and then
running `git reset --hard` and then see whether the bug can be
reproduced)?
Ciao,
Johannes
quoted
On Tue, Jul 19, 2022 at 2:36 PM Kache Hit [off-list ref] wrote:
quoted
Hi. Output of git bugreport:
---
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
Wanted to retain git tree structure when pulling latest and rebasing.
First indication of error was the `rebase -r` of the merge commit
What did you expect to happen? (Expected behavior)
successful --rebase-merges rebase of my commits on top of master
What happened instead? (Actual behavior)
What's different between what you expected and what actually happened?
Anything else you want to add:
I'm currently "stuck" in this state, not sure how to recover or repro:
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.37.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Tue Feb 22 21:10:41
PST 2022; root:xnu-7195.141.26~1/RELEASE_X86_64 x86_64
compiler info: clang: 13.0.0 (clang-1300.0.29.30)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]
pre-commit
pre-push
Hi,
I've not been able to successfully repro this after managing to
recover from it by rebuilding the index:
https://stackoverflow.com/questions/73044253
I'm sorry I couldn't be more helpful.
On Fri, Jul 29, 2022 at 8:59 AM Johannes Schindelin
[off-list ref] wrote:
quoted
Hi Kache,
On Tue, 19 Jul 2022, Kache Hit wrote:
quoted
A thought: the 179457 is reminiscent of something else I did just before this:
I was doing some "code archeology" and was headlessly checking out
some old SHAs in this large monorepo.
During checkout, it said it was updating 174823 files in total.
Do you think it would be possible to whittle this down a bit, and maybe
attempt to come up with a reproducible example? Something like what is
described in https://stackoverflow.com/help/mcve.
If all else fails, and you _only_ manage to reproduce it in the original
repository, could you at least try to figure out a reliable way to get the
Git index into the indicated state (if I were you, I would start off by
switching to the pre-rebase revision, deleting `.git/index` and then
running `git reset --hard` and then see whether the bug can be
reproduced)?
Ciao,
Johannes
quoted
On Tue, Jul 19, 2022 at 2:36 PM Kache Hit [off-list ref] wrote:
quoted
Hi. Output of git bugreport:
---
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
Wanted to retain git tree structure when pulling latest and rebasing.
First indication of error was the `rebase -r` of the merge commit
What did you expect to happen? (Expected behavior)
successful --rebase-merges rebase of my commits on top of master
What happened instead? (Actual behavior)
What's different between what you expected and what actually happened?
Anything else you want to add:
I'm currently "stuck" in this state, not sure how to recover or repro:
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.37.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Tue Feb 22 21:10:41
PST 2022; root:xnu-7195.141.26~1/RELEASE_X86_64 x86_64
compiler info: clang: 13.0.0 (clang-1300.0.29.30)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]
pre-commit
pre-push