Re: Beyond Merge and Rebase: The Upstream Import Approach in Git

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 12, 2023, 15:37 UTC
Message-ID: <xmqq7cr5uonp.fsf@gitster.g>
In-Reply-To: <71f7d816-b139-03ab-88fc-7552d65e4498@gmx.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I know this strategy well, having used it initially to maintain Git for
> Windows' patches on top of Git releases. I refer to it as `rebasing merge`
> strategy.

;-) Thanks. This did look familiar.

Show 9 quoted lines

>    o---o---o---o---o---o---o---o  upstream/main
>         \           \
>          \           o'---o'---o'
>           \                     \
>            o---o---o-------------S---o---o---o  main
>
> A candidate to describe this in a commit range would be
> `upstream/main..main ^S^`, but you cannot pass that to `git rebase -i`,
> which expects a single upstream.

If "git rebase" is taught the `--ancestry-path` option and made to pass it down to the underlying "which commits do I want to replay and in what order" logic, it would be sufficient to help the above topology, I would think. But offhand I do not know what other rev-list options will become useful in different scenarios.

Show 10 quoted lines

> So I switched to a different scheme instead that I dub "merging rebase".
> Instead of finishing the rebase with a merge, I start it with that merge.
> In your example, it would look like this:
>
>    o---o---o---o---o  upstream/main
>         \           \
>          o---o---o---M---o'---o'---o' main
>
> Naturally, `M` needs to be a merge that _must_ be made with `-s ours` in
> order to be "tree-same with upstream/main".

And this will let you say "rebase -i upstream/main" to further rebase the most recent round of commits. That does look quite natural.

Show 6 quoted lines

> This strategy is not without problems, though, which becomes quite clear
> when you accept PRs that are based on commits prior to the most recent
> merging rebase (or rebasing merge, both strategies suffer from the same
> problem): the _next_ merging rebase will not necessarily find the most
> appropriate base commit, in particular when rebasing with
> `--rebase-merges`, causing unnecessary merge conflicts.

Even without rebasing merge or merging rebase, changes, which could be useful if they were not based on a stale base, do happen, and it is more effective to have the original authors of these changes to update them to your most recent tree, than you dealing with them yourself, for two reasons. There are more ICs than you alone, and they are more familiar with their work.

In other words, isn't the real cause of the above that the workflow is not taking advantage of the distributed development? "This PR seems to solve the right problem, but it is based on an old version of the code, please update?"