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 also use gerrit, so that serializes our commits for us. On Fri, Apr 22, 2016 at 2:04 PM, Karthik Kambatla <ka...@cloudera.com> wrote: > 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 for changing this policy so others are in the know? > > Agree tagging releases is good practice. I believe we do this already and > sign, but not sure if we place them under "rel/*" namespace. > > On Fri, Apr 22, 2016 at 12:07 PM, Owen O'Malley <omal...@apache.org> > wrote: > >> 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, 2016 at 11:29 AM, Karthik Kambatla <ka...@cloudera.com> >> wrote: >> >> > 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 recommended we don't >> > force push. For JIRA ID mistakes in commit messages, we have been filing >> > another (possibly empty) commit that just says there was a mistake. e.g. >> > something along the lines of "Mistakenly committed HADOOP-13011 as >> > HADOOP-13001." >> > >> > On Thu, Apr 21, 2016 at 9:42 PM, larry mccay <lmc...@apache.org> wrote: >> > >> > > I believe that he squashed my attempted --amend into a single commit >> on >> > > branch-2.8. >> > > Not sure about trunk and branch-2. >> > > >> > > Thanks for the clarification on the formatting. >> > > I will comply in the future. >> > > >> > > For such issues, is a dev@ email first better than trying to "fix" >> it? >> > > >> > > Again, sorry for the inconvenience. >> > > >> > > On Fri, Apr 22, 2016 at 12:10 AM, Andrew Wang < >> andrew.w...@cloudera.com> >> > > wrote: >> > > >> > > > 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. >> > > > >> > > > >> > > > On Thu, Apr 21, 2016 at 8:26 PM, larry mccay <lmc...@apache.org> >> > wrote: >> > > > >> > > > > 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 rebase to the current history for things to align >> > > > properly. >> > > > > >> > > > > I apologize for the inconvenience. >> > > > > >> > > > > thanks, >> > > > > >> > > > > --larry >> > > > > >> > > > >> > > >> > >> > >
