[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.
Re: GSoC-2020 update: Jul 31, Owen Lamb, 2020/08/03