I did amend the commit to prevent from having two commits per one issue. The reason behind is that we agreed that I will open PR at GitHub and let you to agree or disagree. Nobody replied with yes or no after cca 9 hours which looked like nobody had objections.
Usually I am doing fresh clone from Git and I apply changes from a stash and I use to check every single line and then commit if ok, and git fetch and rebase before push. I use to check GitHub commits before this procedure. On Sun, Jan 8, 2017 at 2:33 AM, Christian Schulte <c...@schulte.it> wrote: > Am 01/08/17 um 01:49 schrieb Fred Cooke: > > Christian, some (potentially unwelcome) advice: Learn to use rebase, > learn > > to fetch, never pull, and review your changes in their new context before > > pushing them. > > I just wasn't used to someone git push --force. As we discussed on dev@, > it would have been way smarter to just "git revert" the commit in question. > > > > > Whether you take the advice, or not, this is how I ensure that my changes > > are clean and focused and coherent, every time. > > I assume "git pull" to not create any conflicts locally if the branch I > am pulling into is what has been pushed. It's the commit to master > having blown up things. > > > > > Pull is a blind operation, which basically says "get whatever is out > there, > > even though I have no idea what it is, and try to merge my changes with > > those changes, regardless, and before reviewing what those changes are". > > I had no local changes and I was suprised a "git pull" creates local > conflicts because someone exchanged master with his personal/feature > branch and force pushed that. Those pushes should not even be possible. > > > If you fetch first you can at least look and make a conscious decision. > Not > > possible if you pull. > > > > This style fits with the Apache "just commit it" mentality, but relies on > > individual developer discipline to work well. The task of "gate keeper" > is > > effectively distributed to each person wanting to push; they gate keep > > themselves, or not. > > > > Fred. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Cheers Tibor
