Re: Commit History Edit Alert

Force pushes break everyone who has been pulling them down, and has the potential to stamp on other people's changes that they got in between the original push and the commit. That's more common in PST than for us in the EU, who can work across all three branches without race conditions

Re: Commit History Edit Alert

FWIW, the Hadoop team at Cloudera, in the past, allowed force pushes for our internal repo. It was common practice to email rest of the team when force-pushing to make sure we don't lose commits. It was quite painful, and we decided to disallow force pushes and life has gotten much better. PS: We

Re: Commit History Edit Alert

Owen, I agree force-pushes likely make for cleaner history, but they also allow losing commits in case of race conditions. Since the previous decision of disabling force pushes was discussed in a DISCUSS thread and others might want to weigh in with their opinions, mind starting a DISCUSS thread

Re: Commit History Edit Alert

In my opinion, prohibiting forced updates causes more pain than it helps. The much more important part is that someone should make tags for the recent releases in the "rel/*" namespace so that they can't be modified. I'd suggest at least: release-2.6.4 release-2.7.2 .. Owen On Fri, Apr 22,

Re: Commit History Edit Alert

Recent changes to branch policies have affected this. Our trunk seems protected, but not branch-* branches. I had filed INFRA-11236 to address this. I can't ping on the JIRA anymore because comments from non-contributors are disabled. To prevent unintentional major messes, it is highly

Re: Commit History Edit Alert

Thanks for the clarification, Andrew. Yes, I'll add a comment about the results of my "testing". :) On Fri, Apr 22, 2016 at 2:06 AM, Andrew Wang wrote: > Squashing means force pushing, so please don't do that per ASF policies. > The normal recommendation is just not

Re: Commit History Edit Alert

Squashing means force pushing, so please don't do that per ASF policies. The normal recommendation is just not to fix it, commit message typos aren't that a big deal. What I do is leave a comment on the JIRA to make it easier for people to track down the commit. I found INFRA-11136 where we

Re: Commit History Edit Alert

What does "fix" mean? We aren't supposed to force push to non-feature branches, and actually thought this was disabled. Also FYI for the future, we normally format our commit messages with periods, e.g.: HADOOP-13011. Clearly Document the Password Details for Keystore-based Credential Providers.

Commit History Edit Alert

All - My first hadoop commit for HADOOP-13011 inadvertently referenced the wrong JIRA (HADOOP-13001) in the commit message. Owen O'Malley helped me out by fixing the history on all 3 branches: trunk, branch-2, branch-2.8. The message is correct now in the current history but you may need to