Skip to content
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

Figure out why 32-bit rebaseall fails on my Windows 10 laptop #361

Closed
dscho opened this issue Sep 7, 2015 · 1 comment
Closed

Figure out why 32-bit rebaseall fails on my Windows 10 laptop #361

dscho opened this issue Sep 7, 2015 · 1 comment
Assignees

Comments

@dscho
Copy link
Member

dscho commented Sep 7, 2015

The idea of rebaseall is to fix that DLL base address problem haunting 32-bit Git for Windows. However, if the rebaseall script itself fails with a "Cannot fork", we are in big trouble.

(I noticed this bug already 4 days ago, and have been hunting it off and on, but only got around to open a proper ticket now.)

@dscho dscho self-assigned this Sep 7, 2015
@dscho
Copy link
Member Author

dscho commented Sep 7, 2015

Progress: rebaseall does not work if msys-2.0.dll already clashes with some DLL loaded into memory because it already fork()s uname and a couple of other calls.

I have started working around this by letting the Git for Windows SDK rebase the DLL base address of msys-2.0.dll itself at the beginning of the installation if running in 32-bit Windows 10: git-for-windows/build-extra@master...dscho:32-bit-issues

Work in progress.

jeffhostetler pushed a commit to jeffhostetler/git that referenced this issue Jul 2, 2021
Replaces git-for-windows#367, which used the upstream commits directly. This instead includes a merge commit onto `vfs-2.32.0` so we can move forward even if the upstream version is modified.

This integrates the sparse-index with `git status`. There is a LOT of code here, and much of it makes future changes (git-for-windows#361 and git-for-windows#364) much simpler than they would be otherwise.

This merges into `features/sparse-index` which is intended to be released as an experimental release. The goal of reviewing this PR is to find "good enough for a limited release to dogfooders" and not the same scrutiny of upstream.

In particular, I am currently looking for an issue with directory/file conflicts at the sparse-checkout boundary. They don't reveal themselves until `git checkout`, and only in very rare cases that won't affect our dogfooders.
jeffhostetler pushed a commit to jeffhostetler/git that referenced this issue Jul 2, 2021
…nd `git checkout`

See gitgitgadget#973 for the upstream submission.

This PR follows git-for-windows#374 which does the heavy lifting.

There is one known issue with this integration: directory/file conflicts at the sparse-checkout boundary. This will not affect our dogfooders so we should ignore that bug for the purpose of the `features/sparse-index` branch. I will fix that upstream.
jeffhostetler pushed a commit to jeffhostetler/git that referenced this issue Jul 2, 2021
…se-index

This follows git-for-windows#374 and git-for-windows#361 to complete the necessary functionality for the sparse-index experimental release.

This does not include the behavior changes requested upstream. The request is about how `git add` currently ignores changes that match a tracked path outside of the sparse-checkout definition. However, this is an established behavior of Git, so we don't need to change it for our dogfooders.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant