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

From: Aleksander Korzyński <ak@akorzy.net>
Date: Jul 14, 2023, 10:56 UTC
Message-ID: <CADWu+UnvastFbWsjfHvJhvS1RBgD8M1LXuA2VMBMSkTqpiLS5w@mail.gmail.com>
In-Reply-To: <xmqqpm4wswny.fsf@gitster.g>

Show 9 quoted lines

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

Show 17 quoted lines

> 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