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

["Aleksander Korzyński" <ak@akorzy.net>]

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

That's a valid point. Let me describe how it used to work.

We tracked a busy project (OpenStack Nova), which used to have as many
as 50 commits per day. At night we used to run an automated job that
would attempt to import the latest upstream (rebase and cauterize),
deploy to a test environment and test it with our configuration. It
would have been impractically slow to require the developer of every
internal patch to manually update to the latest version of the code,
before deploying and testing. Also, it wouldn't be acceptable to an
enterprise to always require the original author to rebase their
patch, because the author may be on holiday or may have left the
company, but the business has to move on.

In the morning, we used to check if the automated job returned green
or red. In practice, however, most of the time our patches would
cleanly rebase automatically without manual intervention. That was
because of the way we used to write the patches - changing as few
lines as possible. Also, patches were typically only temporary in
nature, as they were eventually contributed to the open-source
upstream project.

If the automated job returned red, there was a designated engineer who
would investigate the issue on a given day. They would try to rebase
the patches themselves and fix any issues. If they had any questions
or concerns they would contact the original author, as long as the
original author was at work. Most of the time contacting the original
author wasn't necessary.

> In Git, any commit, be it a single parent commit or a merge, makes
> this statement:
>
>     I considered all the parents of this commit, and it is my belief
>     that it suits the purpose of the branch I am growing better than
>     all of them.
> (...)
> M in the "merging rebase", however, claims that M, i.e. the recent
> upstream, fits the purpose of the branch better than the earlier
> three commits did, which is not quite right.  In contrast, rebasing
> merge does not have such a problem, i.e.
>
>     o---o---o---o---o  upstream/main
>          \           \
>           \           a'---b'---c'
>            \                     \
>             a---b---c-------------M main

I second that observation.

Any other comments? :-)

--
Best regards,
Aleksander Korzynski