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.
