Re: GSoC-2020 update: Jul 31

[Jean Abou Samra]

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.

Best,
Jean