Another is that with rebase, you’re essentially maintaining a clean patchset – your actual commits are always the first in the log, you can always read them as whole solid changes against the current upstream, it’s trivial to submit them upstream.
Rebase works great if there are no projects downstream of you. HardenedBSD does have downstream consumers that require us to maintain a merge-based workflow. Historical commit hashes changing isn’t acceptable for downstream consumers.
git-imerge’s rebase-with-history option is great for this use case. It gives you a rebased view, but where each rebased commit has its old commit as a parent so downstream can merge forwards automatically.
One reason why the rebase workflow is superior :)
Another is that with rebase, you’re essentially maintaining a clean patchset – your actual commits are always the first in the log, you can always read them as whole solid changes against the current upstream, it’s trivial to submit them upstream.
Rebase works great if there are no projects downstream of you. HardenedBSD does have downstream consumers that require us to maintain a merge-based workflow. Historical commit hashes changing isn’t acceptable for downstream consumers.
git-imerge’s rebase-with-history option is great for this use case. It gives you a rebased view, but where each rebased commit has its old commit as a parent so downstream can merge forwards automatically.