On Вт, окт 15, 2019 at 09:16, Frederik Schwarzer
<schwar...@kde.org> wrote:
Am 14.10.2019 22:51 schrieb Johan Ouwerkerk:
On 14.10.2019 21:22, Frederik Schwarzer wrote:
If however, master had seen commits as well, fast-forwarding is
performing a rebase ... is that correct?
The workflow would be: whenever master is updated, you rebase your
local feature/work branch and force-push to the remote copy of the
feature/work branch.
This is exactly the problem I see.
I create a branch.
I start to use, let's say ... KDialog in my feature as KDialog has
been used throughout the application and make 20 commits.
Now on master, someone merges a branch that replaces all the KDialogs
with overlays and removes all KDialog includes.
So if I rebase on that, all my 20 commits will fail to build.
Checking out an older revision to test something will not work.
Now I will fix my latest revision and merge to master. Still: 19
commits are not compiling anymore.
Or am I missing something here?
How would we deal with that? Is "short-lived branches" (as you stated
below) enough to reduce the risk?
Well, usually in a situation like that you, being the author, would
know that previous 19 commits needs fixing as well as the 20th one.
Besides, I think when people would start review, they will probably
notice some odd discrepancy between commits 19 and 20. Or someone just
would remember while reviewing nth commit "Hey, this not gonna work due
to recent changes in codebase".
But yeah, ultimately it's up to you. FWIW: I seem to recall there's a
way to enable automatic merge of a branch once CI passes. However,
running CI for every commit is not implemented yet
https://gitlab.com/gitlab-org/gitlab/issues/25148 Not that I think it's
worth to enable though… The situation you describe seems rare to me,
but it's my subjective opinion, I might be wrong.
