Hmm, then maybe it's better that I refrain from using forced pushes and just leave even trivial changes as separate commits, seems to cause less issues that way.
On Tue, May 28, 2019 at 8:49 PM Matt Sicker <[email protected]> wrote: > Oh, and note that GitHub isn’t typically that great at notifying people in > a PR when a force push happens. More of an issue for reviewers of a PR I > think, not a branch in general. > > On Tue, May 28, 2019 at 12:41, Matt Sicker <[email protected]> wrote: > > > That’s up to you. I’ve been using forks lately because that’s how all > > Jenkins related repositories are configured (we avoid shared branches due > > to some Jenkins issue ironically). > > > > Just note that if you force push to a shared branch, please make sure to > > note that on the dev list so that others know to use `git pull —rebase` > > > > On Tue, May 28, 2019 at 03:35, Andrei Ivanov <[email protected]> > > wrote: > > > >> Sorry about that, I wasn't sure how to handle adding a trivial import > >> cleanup change to my PR, that's why I've ammended the last commit. > >> I wanted to leave the existing commits separate, so squashing wasn't an > >> option (or maybe I could have squashed just the last 2 commits?) > >> > >> Basically I chose option 2 from > >> > >> > https://www.burntfen.com/2015-10-30/how-to-amend-a-commit-on-a-github-pull-request > >> 😕 > >> > >> Maybe I should still use a fork then to work on instead of the main > repo? > >> > >> On Mon, May 27, 2019 at 8:44 PM Matt Sicker <[email protected]> wrote: > >> > >> > It's typically not a great idea to use force push in the main > >> > repositories as they can be shared between people. Whenever I like to > >> > use force push, I usually only do it on my own forks before making a > >> > PR. I don't think anyone else is using this branch, but it's typically > >> > a good idea to avoid force pushing on shared branches (and definitely > >> > not on the master branch). This is more of a note for future reference > >> > since there isn't much you can do here. > >> > > >> > On Mon, 27 May 2019 at 11:12, <[email protected]> wrote: > >> > > > >> > > This is an automated email from the ASF dual-hosted git repository. > >> > > > >> > > shadow pushed a change to branch LOG4J2-2579 > >> > > in repository > >> > https://gitbox.apache.org/repos/asf/logging-log4j-audit.git. > >> > > > >> > > > >> > > discard 8fcfbb5 LOG4J2-2579: add a @EventName to the generated > Java > >> > event interfaces and use it, if available, to generate the event name > >> > > add 998525c LOG4J2-2579: add a @EventName to the generated > Java > >> > event interfaces and use it, if available, to generate the event name > >> > > > >> > > This update added new revisions after undoing existing revisions. > >> > > That is to say, some revisions that were in the old version of the > >> > > branch are not in the new version. This situation occurs > >> > > when a user --force pushes a change and generates a repository > >> > > containing something like this: > >> > > > >> > > * -- * -- B -- O -- O -- O (8fcfbb5) > >> > > \ > >> > > N -- N -- N refs/heads/LOG4J2-2579 (998525c) > >> > > > >> > > You should already have received notification emails for all of the > O > >> > > revisions, and so the following emails describe only the N revisions > >> > > from the common base, B. > >> > > > >> > > Any revisions marked "omit" are not gone; other references still > >> > > refer to them. Any revisions marked "discard" are gone forever. > >> > > > >> > > No new revisions were added by this update. > >> > > > >> > > Summary of changes: > >> > > .../logging/log4j/audit/LogEventFactory.java | 29 > >> > ++++++++++++++-------- > >> > > .../logging/log4j/audit/AuditLoggerTest.java | 7 ++++-- > >> > > 2 files changed, 24 insertions(+), 12 deletions(-) > >> > > > >> > > >> > > >> > -- > >> > Matt Sicker <[email protected]> > >> > > >> > > -- > > Matt Sicker <[email protected]> > > > -- > Matt Sicker <[email protected]> >
