Re: new procedure with GitLab CI

[Jean Abou Samra]

Hi,

Le 05/06/2020 à 11:57, Jonas Hahnfeld a écrit :
> Am Freitag, den 05.06.2020, 11:00 +0200 schrieb Valentin Villenave:
> > On 6/4/20, Jean Abou Samra <jean@abou-samra.fr> wrote:
> > > Actually, I had anticipated a long thread full of reactionson bothof the
> > > above options, but not such a silence. Anyone? (I won't feel offended if
> > > you find my proposal dumb!)
> > Well, you have to account for the fatigue :-)
> >
> > I’m not knowledgeable enough to discuss the benefits and downsides of
> > merge commits vs fast-foward rebase, so I’ll leave it to others.  But
> > I think you make a valid point in that our current linear
> > mandatory-rebase strategy is cumbersome, heavy on the CI pipelines and
> > generating a lot of noise.
> I would like to comment on the last two points:
>   * "heavy on the CI pipelines": The number of pipelines wouldn't change
> with merge commits. We still get one pipeline per push and we would
> want to get testing before a set of changes hits master. This is the
> same as we have right now.
>   * "generating a lot of noise": The only "noise" is the rebase
> operation before merging. Everything else will stay the same: review
> comments, discussion, notifications about pushes, etc.
> NB: I don't see a need to rebase during review. If you chose to do it
> anyway, the same "noise" applies after switching to merge commits.
I agree with you here. On the second point, perhaps the only problem is me:
at the start, I couldn't help clicking on a big green button in the merge
request as I didn't understand the person merging my request in the end 
would
be able to do it. Now that I have the theoretical permission to merge a 
request
but I have not to do that before Patch::push, I've learnt to refrain from
clicking on every tempting button. That said, I note that a contributor
who isn't a member of the group must tick "Allow members to edit this merge
request" or how it's called, otherwise they cannot merge and nobody else can
rebase. That's really minor though, we can certainly live with that.
> The only advantage of merge commits that I agree with is GitLab's
> ability to queue merges and perform them automatically. That may
> qualify as less "cumbersome", but lowering the expectation that every
> merge request in Patch::push must be merged on the same day will get us
> the same result, without any change.
That was the point.
> > The fast-forward rebase has two advantages that I can think of:
> > - the git history is cleaner/easier to parse
I indeed think this is tolerable.
> > - it prevents the situation that sometimes arises where a couple of
> >    patches - that pass testing independently, but will break when
> >    combined - from making it into master (and breaking it)
> This can be avoided by using merge trains which tests the simulated
> merge(s) in order of their queue position:
> https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/
> (We're not using this yet because it only makes sense with proper
> merges, not with rebase + fast-forward.)
Actually, having this sort of testing is exactly the reason why we could
benefit from non-fast-forward merges.

The real problem merge commits pose in my eyes is that they can
make 'git bisect' more difficult. I'm not an expert here, so I'll
ask the question: would it make 'git bisect' completely unusable?
Or just complicate it only in some specific cases?

If a 'git bisect' stays fairly doable, then for me, the advantages of
non-fast-forward merges clearly beat their downsides. That's only
my opinion though.

Best regards,
Jean Abou Samra