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