Hi Flume Community, I have squashed the previously mentioned commits on my fork, I'd be happy if you could have a look on it: https://github.com/adenes/flume/commits/squashed-log4j-upgrade
I have compared the source files with the current trunk (commit: ffc5554), found no difference. I also compiled trunk and my branch and compared the class files, the only difference was the auto-generated ./flume-ng-core/target/classes/org/apache/flume/package-info.class file, which contains the branch name, commit hash, etc. This is the new commit https://github.com/adenes/flume/commit/69c66efefdcd74904986f2727bdf0d52dd9a75e5 which was created by squashing the following commits: fbc7a68 Merge branch 'trunk' into flume-2050 6813d9c Upgrade to Log4j 2.10.0 e4fd6ab Remove more references to log4j 1 6b6605c Update configuration to match log4j 1.x 4bb5e88 FLUME-2050 - modify pattern layout so NDC is ignored if it has no data 4a07fbf FLUME-2050 remove spurious files 140ea5d FLUME-2050 Upgrade to Log4j 2 If there are no objections I'll force push this to the trunk. (Note: it might mess up the git-wip-us.apache.org -> github repo mirroring, if that happens I'll get in touch with Apache Infra to sort it out) Regards, Denes On Wed, Jan 17, 2018 at 12:00 AM Mike Percy <[email protected]> wrote: > I agree squash-before-push is a good policy to maintain a readable commit > history. > > I'd be +1 to doc this and squash the relevant commits. > > Mike > > On Wed, Jan 10, 2018 at 5:37 AM, Denes Arvay <[email protected]> wrote: > > > Hi Hari, > > > > Thank you for your answer. > > I think having one single commit with a structured commit message > belonging > > to one Jira ticket has several benefits: > > - it makes it easier to cherry-pick/backport fixes to release branches > > - simplifies the commit history and avoids having different ways for > > different committers to merge the changes > > - makes it possible to give credit to the authors and reviewers > > > > So I suggest to keep the squash-before-pushing policy but I'm open for > more > > inputs, recommendations as well. > > > > Best, > > Denes > > > > On Tue, Jan 9, 2018 at 10:55 PM Hari Shreedharan < > [email protected]> > > wrote: > > > > > 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 <[email protected]> > 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 > > > > > > > > > >
