Am 07.06.20 um 12:30 schrieb Jean Abou Samra:
> 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
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 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
Am Samstag, den 06.06.2020, 08:57 +0100 schrieb Kevin Barry:
> The fast-forward rebase has two advantages that I can think of:
> - the git history is cleaner/easier to parse
> - it prevents the situation that sometimes arises where a couple of
> patches - that pass testing independently, but
Han-Wen Nienhuys writes:
> On Fri, May 29, 2020 at 7:22 PM Han-Wen Nienhuys wrote:
>> > On 5/27/20, Jonas Hahnfeld wrote:
>> > > No, "rebase" is currently manual (with "merge when pipeline succeeds"
>> > > being automatic). This has been clearly communicated, sorry if you
>> > > missed that.
On Fri, May 29, 2020 at 7:22 PM Han-Wen Nienhuys wrote:
> > On 5/27/20, Jonas Hahnfeld wrote:
> > > No, "rebase" is currently manual (with "merge when pipeline succeeds"
> > > being automatic). This has been clearly communicated, sorry if you
> > > missed that.
> >
> > Hey Jonas, hey everybody;
The fast-forward rebase has two advantages that I can think of:
- the git history is cleaner/easier to parse
- 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
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!)
>
>
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
Le 01/06/2020 à 22:39, Jean Abou Samra a écrit :
David Kastrup wrote:
So I lean towards the following process modeled upon our old one:
No push to master except by automation. Staging is unprotected and gets
scheduled runners. People ultimately rebase and push there once they
get Patch-push
Hi everybody here,Valentin Villenave wrote:
Hey Jonas, hey everybody;
just so you know, I’m getting increasingly frustrated -- as you may
guess if you take a glance at the thread on
https://gitlab.com/lilypond/lilypond/-/merge_requests/95#note_351258804
-- with the GitLab process.
There *are*
Am Freitag, den 29.05.2020, 22:47 +0200 schrieb David Kastrup:
> So I lean towards the following process modeled upon our old one:
>
> No push to master except by automation. Staging is unprotected and gets
> scheduled runners. People ultimately rebase and push there once they
> get Patch-push
Am Freitag, den 29.05.2020, 19:22 +0200 schrieb Han-Wen Nienhuys:
> On Fri, May 29, 2020 at 7:04 PM Valentin Villenave
> wrote:
> > On 5/27/20, Jonas Hahnfeld wrote:
> > > No, "rebase" is currently manual (with "merge when pipeline succeeds"
> > > being automatic). This has been clearly
Hi Valentin,
Am Freitag, den 29.05.2020, 19:03 +0200 schrieb Valentin Villenave:
> On 5/27/20, Jonas Hahnfeld wrote:
> > No, "rebase" is currently manual (with "merge when pipeline succeeds"
> > being automatic). This has been clearly communicated, sorry if you
> > missed that.
>
> Hey Jonas,
Hello
On 29/05/2020 18:03, Valentin Villenave wrote:
-- Issues & Labels. Not that I’m particularly keen to revisit that
matter here; I’ve learned my lesson and stopped trying to intervene
and triage any Issues; it remains to be seen whether
a) Milestones are a good fit to replace
Han-Wen Nienhuys writes:
> On Fri, May 29, 2020 at 7:04 PM Valentin Villenave
> wrote:
>>
>> On 5/27/20, Jonas Hahnfeld wrote:
>> > No, "rebase" is currently manual (with "merge when pipeline succeeds"
>> > being automatic). This has been clearly communicated, sorry if you
>> > missed that.
>>
On Fri, May 29, 2020 at 7:04 PM Valentin Villenave
wrote:
>
> On 5/27/20, Jonas Hahnfeld wrote:
> > No, "rebase" is currently manual (with "merge when pipeline succeeds"
> > being automatic). This has been clearly communicated, sorry if you
> > missed that.
>
> Hey Jonas, hey everybody;
> just
On 5/27/20, Jonas Hahnfeld wrote:
> No, "rebase" is currently manual (with "merge when pipeline succeeds"
> being automatic). This has been clearly communicated, sorry if you
> missed that.
Hey Jonas, hey everybody;
just so you know, I’m getting increasingly frustrated -- as you may
guess if you
On May 27, 2020, at 21:03, David Kastrup wrote:
>
> Dan Eble writes:
>> I wonder how the rest of you feel about having another developer click
>> the buttons to rebase and merge your MRs?
>
> If you refer to me doing that on Han-Wen's merge request, he actually
I had no idea. I just noticed
Dan Eble writes:
> On May 27, 2020, at 07:16, David Kastrup wrote:
>>
>> Now that we have the first "please get in line" merge that isn't
>> actually to any degree unusual, I get the suspicion that my previous
>> alternative proposal of pushing to a CI-less staging branch that then
>> uses CI
On May 27, 2020, at 07:16, David Kastrup wrote:
>
> Now that we have the first "please get in line" merge that isn't
> actually to any degree unusual, I get the suspicion that my previous
> alternative proposal of pushing to a CI-less staging branch that then
> uses CI to get to master will
Jonas Hahnfeld writes:
> Am Mittwoch, den 27.05.2020, 12:17 +0200 schrieb Valentin Villenave:
>> On 5/27/20, Jonas Hahnfeld wrote:
>> > We do want to have the pipeline on the commit before it is merged
>> > because this replaces patchy.
>>
>> Well, that’s absolutely crucial at the MR review
Am Mittwoch, den 27.05.2020, 12:17 +0200 schrieb Valentin Villenave:
> On 5/27/20, Jonas Hahnfeld wrote:
> > We do want to have the pipeline on the commit before it is merged
> > because this replaces patchy.
>
> Well, that’s absolutely crucial at the MR review stage. But after
> passing the
On 5/27/20, Valentin Villenave wrote:
> On 5/27/20, Jonas Hahnfeld wrote:
>> We do want to have the pipeline on the commit before it is merged
>> because this replaces patchy.
>
> Well, that’s absolutely crucial at the MR review stage. But after passing
[sorry, I forgot to end that sentence]
…
On 5/27/20, Jonas Hahnfeld wrote:
> We do want to have the pipeline on the commit before it is merged
> because this replaces patchy.
Well, that’s absolutely crucial at the MR review stage. But after passing
> The only limitation is that all MRs are
> checked individually.
Not only
Am Mittwoch, den 27.05.2020, 10:54 +0200 schrieb Valentin Villenave:
> On 5/27/20, Jonas Hahnfeld wrote:
> > Pinging this to attention...
>
> Yeah, that’s one of those “I’ve read it without fully understanding
> it” situations (and then the discussion devolved into James’s workflow
> and I lost
On 5/27/20, Jonas Hahnfeld wrote:
> Pinging this to attention...
Yeah, that’s one of those “I’ve read it without fully understanding
it” situations (and then the discussion devolved into James’s workflow
and I lost track).
So IIUC there’s no way to skip the rebase-triggered CI pipeline right
Am Samstag, den 23.05.2020, 19:59 +0200 schrieb Jonas Hahnfeld:
> Hi all,
>
> I've now made the necessary settings, merged the changes in
> https://gitlab.com/lilypond/lilypond/-/merge_requests/57, changed all
> existing merge requests to target 'master', and deleted 'staging'.
> I've not
Jonas Hahnfeld writes:
> Am Sonntag, den 24.05.2020, 16:28 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>> > Am Sonntag, den 24.05.2020, 13:19 +0100 schrieb James Lowe:
>> > > So, and you didn't answer this specific question, if I set the label to
>> > > 'review' before the pipeline
Am Sonntag, den 24.05.2020, 16:28 +0200 schrieb David Kastrup:
> Jonas Hahnfeld writes:
> > Am Sonntag, den 24.05.2020, 13:19 +0100 schrieb James Lowe:
> > > So, and you didn't answer this specific question, if I set the label to
> > > 'review' before the pipeline runs will make doc still run?
>
Am Sonntag, den 24.05.2020, 14:37 +0100 schrieb James Lowe:
> > But what if a patch in countdown is rebased (without a diff) and is
> > currently running? Should it be put back to Patch::new and afterwards
> > skip the labels until Patch::countdown? That sounds very confusing to
> > me...
>
> I
Jonas Hahnfeld writes:
> Am Sonntag, den 24.05.2020, 13:19 +0100 schrieb James Lowe:
>
>> So, and you didn't answer this specific question, if I set the label to
>> 'review' before the pipeline runs will make doc still run?
>
> Sorry: Yes, CI pipelines will run irrespective of the labels.
One
On 24/05/2020 14:11, Jonas Hahnfeld wrote:
Am Sonntag, den 24.05.2020, 13:19 +0100 schrieb James Lowe:
On 24/05/2020 12:09, Jonas Hahnfeld wrote:
You should see it at the individual MR, can you check
https://gitlab.com/lilypond/lilypond/-/merge_requests/82
?
I am still not certain. Sorry to
Am Sonntag, den 24.05.2020, 13:19 +0100 schrieb James Lowe:
> On 24/05/2020 12:09, Jonas Hahnfeld wrote:
> > You should see it at the individual MR, can you check
> > https://gitlab.com/lilypond/lilypond/-/merge_requests/82
> > ?
>
> I am still not certain. Sorry to be a pain here.
>
> !83 and
On 24/05/2020 12:09, Jonas Hahnfeld wrote:
Am Sonntag, den 24.05.2020, 11:41 +0100 schrieb James Lowe:
OK. Using Masamichi's MR as an example (nothing personal Hosoda-san!) I
saw that his MR !81 came up via countdown.py - I am using the latest
update of this BTW - so looking at this MR via the
> I can't tell you for sure either. It could be that the fork at
> https://gitlab.com/trueroad/lilypond has Pipelines enabled, but only
> visible to project members. Hosoda-san, could you check this in your
> project? The drop-down is at Settings > General > Visibility ... >
> Pipelines. I'm
Am Sonntag, den 24.05.2020, 11:41 +0100 schrieb James Lowe:
> OK. Using Masamichi's MR as an example (nothing personal Hosoda-san!) I
> saw that his MR !81 came up via countdown.py - I am using the latest
> update of this BTW - so looking at this MR via the web I could not tell
> if this had
On 24/05/2020 08:59, Jonas Hahnfeld wrote:
Hi James,
Am Samstag, den 23.05.2020, 19:08 +0100 schrieb James Lowe:
Jonas,
On 23/05/2020 18:59, Jonas Hahnfeld wrote:
Hi all,
I've now made the necessary settings, merged the changes in
https://gitlab.com/lilypond/lilypond/-/merge_requests/57,
Hi James,
Am Samstag, den 23.05.2020, 19:08 +0100 schrieb James Lowe:
> Jonas,
>
> On 23/05/2020 18:59, Jonas Hahnfeld wrote:
> > Hi all,
> >
> > I've now made the necessary settings, merged the changes in
> > https://gitlab.com/lilypond/lilypond/-/merge_requests/57, changed all
> > existing
On May 23, 2020, at 13:59, Jonas Hahnfeld wrote:
>
> Hi all,
>
> I've now made the necessary settings, merged the changes in
> https://gitlab.com/lilypond/lilypond/-/merge_requests/57, changed all
> existing merge requests to target 'master', and deleted 'staging'.
This helped me update the
Jonas,
On 23/05/2020 18:59, Jonas Hahnfeld wrote:
Hi all,
I've now made the necessary settings, merged the changes in
https://gitlab.com/lilypond/lilypond/-/merge_requests/57, changed all
existing merge requests to target 'master', and deleted 'staging'.
I've not rebased the existing merge
Hi all,
I've now made the necessary settings, merged the changes in
https://gitlab.com/lilypond/lilypond/-/merge_requests/57, changed all
existing merge requests to target 'master', and deleted 'staging'.
I've not rebased the existing merge requests and there's no need to do
so if it's already
41 matches
Mail list logo
