[Top][All Lists]

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

Re: GSoC-2020 update: Jul 31

From: Jean Abou Samra
Subject: Re: GSoC-2020 update: Jul 31
Date: Sat, 1 Aug 2020 23:31:32 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Hi everyone,

Le 01/08/2020 à 18:19, Urs Liska a écrit :
Am 1. August 2020 16:12:24 MESZ schrieb Werner LEMBERG <>:
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.


reply via email to

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