[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new procedure with GitLab CI

From: Jean Abou Samra
Subject: Re: new procedure with GitLab CI
Date: Sun, 7 Jun 2020 12:30:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0


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 <> 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:
(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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]