Re: Gitlab Migration

[Dmitry Gutov]

On 29.08.2021 10:42, Drew DeVault wrote:
> On Sun Aug 29, 2021 at 9:38 AM CEST, Eli Zaretskii wrote:
> > Rebasing is not just intimidating, it has real problems as well. One
> > problem that particularly bothers us is that it could, in some
> > circumstances, cause the same commit to be present more than once.
> >
> > I find a hard requirement to use rebase to be user-unfriendly, because
> > some of us simply don't want to rebase, for reasons of preserving the
> > original history of the development. Is rebasing really a requirement
> > in SourceHut?
> No, it's not a requirement. It's just something I think is a good idea.

When you say it's not a requirement, how does the alternative work?

Suppose I have a feature branch scratch/exciting-new-feature.

And it has a number of existing commits A, B, C, where I did some work 
on said feature.

Then I do a merge from master, creating a merge commit M which resolves 
a conflict. It also pulls commits M1 and M2 from master into the branch, 
both of which have a later creation date than A.

Then I add commits D and E with some subsequent work.

What do I do next, to submit the new version of the code?

If I try to submit that branch's contents from the web UI, and I need to 
select all the commits which include the work:

- Does the Prepare Patchset UI show commits M1 and M2? What happens if 
they get selected (residing chronologically between A and E)?

- Does the Prepare Patchset UI show the merge commit M? If yes, what 
happens with it later if the patchset gets approved? Does it turn into a 
"real" merge commit?