Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?

2019-10-15 Thread Albert Astals Cid
El dimarts, 15 d’octubre de 2019, a les 9:16:48 CEST, Frederik Schwarzer va escriure: > > 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 corre

Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?

2019-10-15 Thread Ben Cooksley
On Wed, 16 Oct 2019, 05:17 Johan Ouwerkerk, wrote: > On Tue, Oct 15, 2019 at 9:17 AM Frederik Schwarzer > wrote: > > 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

Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?

2019-10-15 Thread Johan Ouwerkerk
On Tue, Oct 15, 2019 at 9:17 AM Frederik Schwarzer wrote: > 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

Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?

2019-10-15 Thread Konstantin Kharlamov
On Вт, окт 15, 2019 at 09:16, Frederik Schwarzer 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 m

Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?

2019-10-15 Thread Frederik Schwarzer
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 a