Loosening the commit limit for work branches

[Noah Davis]

A week ago, I ran into an unexpected issue while working on a QML port
of Spectacle. There is an undocumented pre-receive hook that sets a
100 commit limit for all branches of official repos, including work
branches. The error message it gave me told me to file a sysadmin
ticket, so I did that.

The sysadmin ticket link: https://phabricator.kde.org/T15683

I don't think I can make the ticket public, so here's the conversation:

--- Start of conversation

ndavis (me):
For normal branches, I would understand this since there were issues
with spamming #kde-devel in the past. This isn't necessary for work
branches, right? I thought the point of the work/ naming convention
was to prevent this issue.

bcooksley:
Work branches weren't meant to be used for large feature developments
with 100+ commits in them, which is why this is being blocked.
In it's current state - even if rebased - the branch will not be able
to be merged without Sysadmin intervention.
Will this be squashed prior to being merged?

ndavis:
> Will this be squashed prior to being merged?

Yes

> Work branches weren't meant to be used for large feature developments with 100+ commits in them, which is why this is being blocked.

Is this documented anywhere? I don't understand why work branches
would block this. The git message says notifications are the reason
why the push was blocked, but I thought work branches didn't send
notifications?

bcooksley:
The message is a little misleading, but that is mostly because this
situation isn't supposed to really occur. You are correct that work
branches don't send notifications.
As such it is not documented anywhere.
>From a policy perspective the reason why we don't allow work branches
to grow beyond 100 commits is because if we did then you would never
be able to merge them in - not without squashing anyway.
This therefore makes you "squash as you go".
I would generally recommend that major features be developed in an
ordinary branch to allow those that monitor kde-commits and other
commit feeds to chime in with real-time reviews, and then merged using
a traditional Git merge (vs. our more typical rebase)

ndavis:
> The message is a little misleading, but that is mostly because this situation isn't supposed to really occur. You are correct that work branches don't send notifications. As such it is not documented anywhere.

If we are going to keep this limitation, we should document it so that
nobody else makes the same mistake as me. We can't assume that
something that isn't supposed to happen won't happen because there's
no reason to assume this limitation would exist.

> From a policy perspective the reason why we don't allow work branches to grow beyond 100 commits is because if we did then you would never be able to merge them in - not without squashing anyway.
This therefore makes you "squash as you go".

I don't understand why we have this policy. If we can't merge an MR
with over 100 commits, why can't we just tell the person making an MR
when they post the MR to squash it? I think it would make more sense
for this policy to apply only when pushing to master or version
branches.

> I would generally recommend that major features be developed in an ordinary branch to allow those that monitor kde-commits and other commit feeds to chime in with real-time reviews,

In my experience, nobody does that. Nobody has time to review unless
you explicitly request help or you post an MR.
I don't know the protocol for discussing these kinds of things, so let
me know if this discussion should be moved elsewhere.

--- End of conversation

After this, I decided it would be better to discuss this with the
broader KDE community and I closed the ticket.

I did try to switch to a normal branch as Ben Cooksley suggested, but
that had the same limitation. I have not tested using a fork, but some
of the people I've talked to casually (I can't remember who) seemed to
be saying that fork branches don't have this limitation, which I think
would make the limit on work branches kind of pointless if it's true.

I understand the concern about making unmergeable merge requests, but
I don't think a hard 100 commit limit pre-recieve hook is the right
way to deal with that. That's something that should be handled by
reviewers, not automated systems, because sometimes info needs to be
kept until it is time to merge. Instead of having lots of small
commits to keep track of each change as much as possible until it's
time to review the MR, I've had to squash them into mega commits with
lines in the commit message for each commit that got squashed.
Normally, I would squash at the end of the review process to ensure
that all relevant info is kept and irrelevant info is discarded.

What does the broader KDE development community think? Should there be
a commit limit and how large should it be? Only KDE devs can make work
branches, so the pool of people who can make branches with large
amounts of commits is already fairly limited.