lilypond-devel
[Top][All Lists]
Advanced

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

Re: GSoC-2020 update: Jul 31


From: Urs Liska
Subject: Re: GSoC-2020 update: Jul 31
Date: Sun, 02 Aug 2020 04:56:32 +0200
User-agent: K-9 Mail for Android


Am 1. August 2020 23:31:32 MESZ schrieb Jean Abou Samra <jean@abou-samra.fr>:
>Hi everyone,
>
>Le 01/08/2020 à 18:19, Urs Liska a écrit :
>> Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG <wl@gnu.org>:
>>>>> Another issue: Maybe it makes sense if you try to rebase your 
>>>>> branch from time to time. 
>>>> Really rebase? 
>>> Yes, I favour rebasing over merging since the former causes a 
>>> `prettier' git commit tree.
>>>> This would be a case where "general wisdom" argues against
>modifying 
>>>> pushed commits. Typically you'd rather merge master into your 
>>>> working branch here. 
>>> Well, there's a good reason that gitlab has a big, fat 'rebase' 
>>> button... 
>
>Not sure about the meaning of your message: this button shows up
>because 
>we enabled it as a project-wide setting. To my knowledge, the default 
>and most common strategy is merging.
>
>> Yes, but that is meant to deal with integrating the final result into
>
>> master. Rebasing during work means that Owen's commits don't match 
>> those pulled by others. I don't have a strong opinion here but it 
>> should be an agreed-upon procefure for all.
>
>While I generally prefer merging over rebasing, since we enforce an 
>all-fast-forward policy for merging to master, I think we should rebase
>
>here. My reasoning is that you put in more information when resolving 
>conflicts during a rebase: merging means you unify two diverging 
>histories, thus you get prompted once and for all, but rebasing forces 
>you to resolve conflicts for each intermediary commit. As far as my 
>understanding extends, if Owen merges now, there will still be work
>left 
>for rebasing at the end of the project, part of which will be 
>duplicated. By contrast, rebasing now means less error-prone work in
>the 
>future.

That sounds reasonable.

However, it means everybody should expect commits to change after having looked 
at rhem. So: always pull again (well, that's clear) and never add commits to 
Owen's branch wirhout clarifying the state directly with him.

Urs
>
>Best,
>Jean

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.



reply via email to

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