I don't have any objections to that, but I have to wonder if it makes sense to update the guidelines to actually not have to squash commits. I think the reason we needed to squash those commits was that we were originally on SVN and having multiple commits didn't make much sense in SVN. It is easy to track history with a single commit, but that looks to be the case anyway (I just see 1 merge commit, which is fine - it is an artifact of pull request merges).
That said, I don't have an objection to force-pushing, we just need to make sure no history is lost. On Tue, Jan 9, 2018 at 1:03 AM, Denes Arvay <de...@cloudera.com> wrote: > Hi Flume Community, > > A couple of commits went in to trunk recently which weren't in line with > our commit guidelines. > I suggest to squash these commits to one and do a force push to resolve > this issue, plus - as the guidelines are not clear enough - I'd like to > extend the > https://github.com/apache/flume/blob/trunk/dev-docs/HowToCommit.md doc to > be more concrete on the requirements for a commit. These rules are > currently mostly unwritten, so it'd be useful to clarify them. > > I'm happy to do these if there is no objection from the community. > > Regards, > Denes >
