Re: GSoC-2020 update: Jul 31

[Owen Lamb]

Wow!

Thanks everyone... even if a lot of this went over my head. I've never
rebased before, so I can't say what would be the better option.

At any rate, my understanding is that I'll organize my commits near the end
of the project to make sure everything is reviewable, correct? If that's
the case, it might just be good to wait until then before I rebase and/or
merge anything.

Thanks,
Owen

On Sat, Aug 1, 2020 at 11:21 PM Jonas Hahnfeld via Discussions on LilyPond
development <lilypond-devel@gnu.org> wrote:

> Am Samstag, den 01.08.2020, 23:31 +0200 schrieb Jean Abou Samra:
> > 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.
>
> But only for conflicts that git detects. For example, it doesn't
> guarantee at all that every intermediate commit can be built afterwards
> (in fact, I rather find this unlikely for larger changes).
>
> > 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.
>
> I think we're not going to just merge (in whatever way) all commits
> from the branch to master at the end of the summer, are we? Eventually
> this means the changes need to be split into reviewable chunks, as is
> also a policy of the project.
> For now, I'd leave the branch where it is. At least this guarantees
> that all commits work the way Owen wrote them.
>
> Jonas
>