On 6/15/20 1:46 AM, Bhushan Shah wrote:
On Mon, Jun 15, 2020 at 09:21:53AM +0300, Vlad Zahorodnii wrote:
I agree that the interactive rebase tool is difficult to master, but we
could provide an example of recommended gitlab workflow on our wiki and
point newcomers to it. By doing so, we will hel
On Mon, Jun 15, 2020 at 09:21:53AM +0300, Vlad Zahorodnii wrote:
> I agree that the interactive rebase tool is difficult to master, but we
> could provide an example of recommended gitlab workflow on our wiki and
> point newcomers to it. By doing so, we will help the newcomers grow
> professionally
On Sun, Jun 14, 2020 at 11:06:28PM +0100, David Edmundson wrote:
> - We had a discussion about how to make review queues a big more
> manageable.
> We intend to use some labels.
>
> Action plan is to copy + paste the labels Krita uses...as if it works for
> them, they're probably good enough. Bsh
So to clarify, there are two allowed gitlab workflows.
MRs for chains of nicely done rebased commits
MRs where one MR represents a single logical commit to be squashed and the
list of actual commits uploaded is garbage.
>
> One issue with such a workflow is that code reviewers will have to
> acc
Hi,
On 6/15/20 1:06 AM, David Edmundson wrote:
- There was a discussion on the two different styles of use gitlab
use. Some people squash locally and have a nice neat commit history.
Others don't, and then just squash at end.
- Conclusion was it's unreasonable to get devs to squash an
- Generally working well
- There seems to be an uptick in new contributors \o/
- We had a discussion about how to make review queues a big more
manageable.
We intend to use some labels.
Action plan is to copy + paste the labels Krita uses...as if it works for
them, they're probably
