Hi Folks,
Joel Brobecker <brobec...@adacore.com> wrote:
You should include Joel on such questions as the expert on the hooks.
I don't know whether there's something to put in the commit message to say
"allow this merge of more than 100 commits". I don't think a squashed
merge is the right workaround, supposing you do want the git ancestry
information to reflect what got merged. The simple workaround is to do
three successive merges, each of under 100 commits and each pushed
separately. Alternatively, you could check out refs/meta/config, push a
change that either increases hooks.max-commit-emails or sets
hooks.no-emails to prevent mails for this branch, then push the merge,
then push a reversion of the change to refs/meta/config.
Joseph pretty much nailed it in terms of options.
Yeah - I agree.
I didn’t do the squash merge because I don’t want to lose the ancestor
history
on the branch.
For the sake of separating the process of merging coroutines from our general
git policies, I am going to use several smaller merges - this is a simple and
transparent workaround.
I think editing the hooks would be less transparent and doesn’t solve the
‘spamming the commits ML’ any better.
---
As I noted, 100 commits to master is a small number, so I expect this problem
to fire almost every time someone does a merge of master to a devel or user
branch (unless they have the habit of doing that almost daily, which I
doubt for
most).
thanks
Iain
