Not at the moment, and probably not for v1.0 unless that bubbles up as a huge blocker.
You could accomplish it with something like:
- Make the changes in your branch
- Make a new branch off of `main` and cherry-pick the changes you want from your branch into that new one
- Commit and promote from the new branch; at this point you can delete the new branch
- Auto-rebase will run and propose a good merge to your original branch, which would include the partial changes you now have both in `main` and in your branch.
I still have to write cherry-pick - not sure that I'll call it that - and promotion conflict processing using LLM's. But something like the above steps would do what you're asking without too much effort.
There's no way to tackle the entire surface area of 20 years of Git in one release. I'm sure we'll see workarounds like that in v1.0 and learn from them to improve 2.0 and 3.0.
Not at the moment, and probably not for v1.0 unless that bubbles up as a huge blocker.
You could accomplish it with something like:
- Make the changes in your branch - Make a new branch off of `main` and cherry-pick the changes you want from your branch into that new one - Commit and promote from the new branch; at this point you can delete the new branch - Auto-rebase will run and propose a good merge to your original branch, which would include the partial changes you now have both in `main` and in your branch.
I still have to write cherry-pick - not sure that I'll call it that - and promotion conflict processing using LLM's. But something like the above steps would do what you're asking without too much effort.
There's no way to tackle the entire surface area of 20 years of Git in one release. I'm sure we'll see workarounds like that in v1.0 and learn from them to improve 2.0 and 3.0.