Why did git-for-windows switch to the merging-rebase fork strategy? #4821
-
|
I came across the merging-rebase strategy used by git-for-windows in a GitHub blog post, which notes:
I found some wiki pages that document the strategy and some tools and tips on how to perform these rebases. But I'm very curious: why did @dscho develop this strategy to replace the simple merge strategy? What were the needs mentioned in the quote above? I am going to be maintaining a private fork of a public repository, and the answer will help me decide between the simple merge and the merging rebase strategies for our use case. Thank you in advance for sharing your experience! |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 9 replies
-
|
The main reason to use rebases in the first place is to keep our patches in an upstreamable shape. A secondary reason is to make integrating new upstream versions easier: it is too easy to overlook when changes outside the merge conflicts are problematic, especially when entire commits become obsoleted by upstream commits. The challenge with rebases is that it would require force-pushing, and that just messes with PRs that are still in flight. So I invented first the rebasing merge (where it was easy to find out the latest rebased commit), and later switching to a merging rebase (where it is easy to find out the oldest rebased commit, which is a much more common question to answer). In |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the quick answer and for sharing your experiences. Could you give me some pointers to understand the exact details and differences between the rebasing merge and the merging rebase? I'm guessing the latter is the one that is now supported by I guess the downside with |
Beta Was this translation helpful? Give feedback.
-
First of a,, no, The only tool that does merging rebases is https://github.com/git-for-windows/build-extra/blob/main/shears.sh. Let me demonstrate the difference via a small example. Let's take this commit history: A simple merge would do this: The advantage would be that contributors can still keep their PRs as-are, maybe needing minor merge conflict resolutions. The disadvantage is that the commits in the A simple rebase would do this: Advantage: upstreamable state, it's easier to spot when parts of a commit in the Disadvantage: disconnected histories, contributors have to re-target their PRs. The rebasing merge did this: In other words, it is a rebase that is followed by a fake merge that pulls in the previous commit history but keeps the actual tree contents identical to its first parent (i.e. the tip of the rebased commits). The advantage is that PR branches naturally fast-forward to the new tip commit. The disadvantage of this approach is that while the patches are in an upstreamable shape, it is not necessarily easy to come up with a commit range that identifies those upstreamable commits. Keep in mind that there could have been new commits after the fake merge. The commit range would have to be something like The merging rebase overcomes this problem by doing this instead: In other words, it starts from a clean upstream slate, first fake-merges the previous commit history, and then applies the rebased commits. By having a strict naming convention (the For scenarios where the obsoleted commits are undesirable, it is relatively easy to add a replace object:
Yes. In general, having release branches even requires a PR per new release branch, not just a retargeting.
Yes, and a re-targeting (you need to click the
That would be suboptimal. A rebase would be much cleaner. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! The example, in particular, was super helpful.
If you have a moment, could you elaborate on this? Would an example of this situation be if git-for-windows removed entire files from git, and new upstream version changed that file? Thanks again. |
Beta Was this translation helpful? Give feedback.
-
|
No, an example would be if a commit introduced a new function and declared it in a slightly different location than the version of the patch that made it upstream. With a simple merge, there wouldn't be any conflicts. You'd have to do a full review of a first-parent diff, which is... daunting. With rebasing there isn't any merge conflict, either, but the problem would be immediately obvious in the range-diff we use to double-check whether all of Git for Windows' patches were rebased correctly. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed answer @dscho, I'm also considering what strategy to choose for our in-house forks. Our repositories are not high-velocity so we do not have a lot of open PRs at any given time, so this advantage of merging-rebase is not super important too me. But, I'd really like if you would share your experience on how having the "whole" history reachable from the tip of the fork is valuable. That is, what do I gain by using a merging rebase strategy, that is not possible (or harder) if previous versions of the fork's main branch are just available as tags (i.e. we just do a regular Also, you write:
Is this workaround caused by the fact that having the original commits reachable somehow "confuses" the 3-way merge algorithm, and so it selects a non-ideal merge-base? Do you have concrete examples of when this workaround was needed? I have a feeling this is related to what Junio writes here... Thanks, |
Beta Was this translation helpful? Give feedback.
-
It allows me to look through the history of a patch. For example, to see how the "README.md: Add a Windows-specific preamble" patch evolved over time, I simply run: prev= &&
for c in $(git rev-list --reverse --grep="README.md: Add a Windows-specific preamble" origin/main)
do
test -z "$prev" ||
git range-diff "$prev^!" "$c^!"
prev=$c
doneOutput
There is actually only one scenario where I use this myself, and it is vaguely related to what Junio mentions here: When I merge an upstream branch as-is (i.e. not rebased on top of Git for Windows' |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot, this is very useful insight. |
Beta Was this translation helpful? Give feedback.
-
|
Another thing merging-rebases enables is to easily compare pre- and post-rebase patches (e.g. to ensure that nothing was lost). I do this in Git for Windows' rebase PRs all the time, see e.g. #4816 (comment). That range-diff can be easily regenerated using: |
Beta Was this translation helpful? Give feedback.
-
|
Yes, this is useful. But if I understand correctly, it is not strictly needed if no topic branch merges "cross" a merging-rebase commit right? In that case you could simply do this: git range-diff v2.43.0..v2.43.0.windows.1 v2.44.0-rc1..v2.44.0-rc1.windows.1is that correct ? |
Beta Was this translation helpful? Give feedback.
-
|
If there was no merging-rebase, you could do that. But you'd need to carefully construct the commit ranges (in a non-automatable way). I have a Git alias for this, which only works because of the merging-rebase. |
Beta Was this translation helpful? Give feedback.
-
A personal viewpoint of the strategy is that:
Hopefully that doesn't conflict with Dscho's realpolitik of how it actually came about. [aside: a '--no-theirs' option when commit walking would essentially drop merges where there is a matching parent and child tree, and just follow the matching tree in the commit walk]. |
Beta Was this translation helpful? Give feedback.
The main reason to use rebases in the first place is to keep our patches in an upstreamable shape.
A secondary reason is to make integrating new upstream versions easier: it is too easy to overlook when changes outside the merge conflicts are problematic, especially when entire commits become obsoleted by upstream commits.
The challenge with rebases is that it would require force-pushing, and that just messes with PRs that are still in flight. So I invented first the rebasing merge (where it was easy to find out the latest rebased commit), and later switching to a merging rebase (where it is easy to find out the oldest rebased commit, which is a much more common question to answer).
In
mi…