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

[Junio C Hamano <gitster@pobox.com>]

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.

>    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.

> 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.

> 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?"