lilypond-devel
[Top][All Lists]
Advanced

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

Re: PATCHES - Countdown for May 15th


From: Jonas Hahnfeld
Subject: Re: PATCHES - Countdown for May 15th
Date: Sat, 16 May 2020 11:15:09 +0200
User-agent: Evolution 3.36.2

Am Freitag, den 15.05.2020, 21:32 +0200 schrieb Jonas Hahnfeld:
> Am Freitag, den 15.05.2020, 16:57 +0100 schrieb Kevin Barry:
> > On Fri, May 15, 2020 at 04:25:52PM +0200, Jonas Hahnfeld wrote:
> > > That the script is doing exactly what I told it to do: The diff between
> > > the previous and the rebased commit is not empty. Therefore it adds the
> > > Patch::new label, removing Patch::push.
> > 
> > Shouldn't `diff staging...HEAD` be the same before and after a rebase
> > (three dots)?
> 
> Yes, I think this works as long as staging not already includes some
> (rebased) commits that were previously part of the merge request. We
> could of course determine the merge base between the old and new commit
> which should also avoid that case.

My thinking was wrong here: The common merge base of the two commits
results in a larger diff for the new commit because it now includes all
commits since the merge base, which is not what we want.
So I went with Kevin's original suggestion with one modification: The
staging branch is a moving target. Depending on when the webhook runs,
the rebased commits might have already landed which makes the diff
empty. Instead I ask GitLab for the diffs relative to the respective
base commits. I think this does the right thing (tm), at least in my
testing.

I already deployed the change to my server, here for reference: 
https://gitlab.com/lilypond/infrastructure/-/merge_requests/4
Testing in the repo and feedback would be welcome!

Jonas

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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