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
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
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.
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 (which I have more experience with),
any new commits to your branch should automatically be picked u
>> Am I misunderstanding something? Or is what it says in 3.2 a
>> mistake?
>
> If GitLab works similar to GitHub
In this case, it does not, or rather, we don't want what is standard
on GitHub.
> any new commits to your branch should automatically be picked up as
> part of the open merge/pull
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 (which I have more experience with),
any new commits to your branch should automatically be picked up as part
of the open merge/pull request.
11 matches
Mail list logo
