Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'lilypond' has been submitted
by the Chinese (simplified) team of translators. The file is available at:
https://translationproject.org/latest/lilypond/zh_CN.po
(We can arra
Here is the current countdown report.
The next countdown will begin on January 23rd.
A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority
Push:
!1813 Fix issue 6521 - Thomas Morley
https://gitlab.com/lilypond/lilypond/-
Le 20/01/2023 à 23:45, David Zelinsky a écrit :
Note that it's not strictly necessary that a merge request consists of
one commit only: Logically independent "smallish" commits are fine
(possible example: one commit for the feature, one for the larger
documentation revision the feature necessitat
Le 20/01/2023 à 15:03, Aaron Hill a écrit :
On 2023-01-20 3:22 am, Jean Abou Samra wrote:
Rewriting history is just something that one might not be used to coming
from other projects, but perfectly fine for our purposes.
It was impressed upon me to treat rewriting history as fraught with
peri
Lukas-Fabian Moser writes:
> Am 20.01.23 um 07:38 schrieb Aaron Hill:
>
>> On 2023-01-19 8:54 pm, David Zelinsky wrote:
>>
>>> Am I misunderstanding something? Or is what it says in 3.2 a mistake?
>>
>> If GitLab works similar to GitHub ...
>
> Accepted practice in lilypond development is differ
[In case people are wondering why I’m not replying: I want to actually see what
it takes to cross-compile Poppler, this takes time, and I don’t have a lot of
it ATM, hence the delay.]
At first I saw it like you Aaron,
but after thinking about this for the last several hours it occurred to me
that we're only rewriting the history of the current MR, we're not junking
a big part of the project.
The idea is that given that there's no squash upon acceptance, the history
in the MR wil
On 2023-01-20 3:22 am, Jean Abou Samra wrote:
Rewriting history is just something that one might not be used to
coming
from other projects, but perfectly fine for our purposes.
It was impressed upon me to treat rewriting history as fraught with
peril, potentially even Bad(tm) in the Ghostbust
Le 20/01/2023 à 08:05, Lukas-Fabian Moser a écrit :
(Personally, I use two local branches for developing a feature: one in
which I keep track of my progress by adding commit after commit, and
one which is the "squashed" version that I update with amend/squash
and use for pushing. git's interact
Le 20/01/2023 à 10:36, Aaron Hill a écrit :
On 2023-01-19 11:01 pm, Werner LEMBERG wrote:
[SNIP]
Nope. The preferred way is to make the MR's commit as pretty as
possible. No final squashing.
That *almost* seems like squashing, but with more steps. Certainly,
there is nothing to squash if ev
Yes, I mean the Google Group
Il giorno ven 20 gen 2023 alle 20:43:02 +1100, Andrew Bernard
ha scritto:
Where is the Frescobaldi mailing list? Do you mean Google Groups?
Andrew
On 20/01/2023 8:09 pm, Federico Bruni wrote:
The answer to the other questions is more complex. We are working on
Where is the Frescobaldi mailing list? Do you mean Google Groups?
Andrew
On 20/01/2023 8:09 pm, Federico Bruni wrote:
The answer to the other questions is more complex. We are working on
it... I will reply to your question in the Frescobaldi mailing list.
On 2023-01-19 11:01 pm, Werner LEMBERG wrote:
[SNIP]
Nope. The preferred way is to make the MR's commit as pretty as
possible. No final squashing.
That *almost* seems like squashing, but with more steps. Certainly,
there is nothing to squash if everything is expressed neatly in one
commit.
13 matches
Mail list logo
