>> "Here the top of commit has commit has c14cdd3673ebdd8014118ec961068ee51f2327b1,
instead of a1b9460dbfaf9e96aa958d805cf6cf11c8d01d0f, which is expected. " is
one of the things which lead me to my conclusions.
This was referring to two different commits, instead of the same commit
that mutated to two different commit hashes.
>> It's one of the reasons why I thought/think force pushes should be
This was done in https://issues.apache.org/jira/browse/INFRA-13968
worries moving forward.
>> I'm not sure we'll ever know at this point.
I think it would be good to know what caused this. My bet is on the svn-git
move still, so I left a comment onhttps://issues.apache.org/jira/browse/INFRA-12573
, let's see what Infra
says about this.
Though, we probably can't do anything about this (like revert to old commit
hash), and the current status might be OK as it's not malicious.
On Tue, Sep 12, 2017 at 1:12 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 12, 2017 at 12:19 PM, Michael Han <[EMAIL PROTECTED]> wrote:
> > Hi Pat,
> > I still think it is the svn git migration - or at least something other
> > than, or in combination with the force push commit that causes this. One
> > proof is, one of the forked repo already has commit hash difference
> > comparing to the old repos:
> > Forked Repo:
> > https://github.com/rakeshadr/zookeeper-1/commit/
> > d497aac4cf8cf2144a377e46011385b20fc74fa6
> > Old Repo:
> > https://github.com/autodesk-forks/zookeeper/commit/
> > ebd64c4a9b62876f7054add6a07bd36581916557
> > And this commit was made before we did the svn-git move.
> > Please also note that the forked repo here does not contain the forced
> > commit - so the commit has difference was created before the forced push
> > happened. For reference, the forced push commit was to reset the HEAD (at
> > the time that commit was made) to this one:
> > https://github.com/apache/zookeeper/commit/
> > e51f2327b1
> > If on the other side it's the forced commit push that causes this, we
> > should expect the same commit hashes for the commits I mentioned above
> > right?
> Based on what I've seen so far I don't know what happened. However your
> comment on the jira here
> "Here the top of commit has commit has
> c14cdd3673ebdd8014118ec961068ee51f2327b1, instead of
> a1b9460dbfaf9e96aa958d805cf6cf11c8d01d0f, which is expected. "
> is one of the things which lead me to my conclusions.
> I'm not sure we'll ever know at this point. It's one of the reasons why I
> thought/think force pushes should be disallowed, in particular because it's
> so hard to know what happened when and track the impact.
> From what I can see at this point in time, while the hashes differ it looks
> like it's not malicious, which is my primary concern. I diffed some of the
> branches and while the hash differs I have not see diffs in the code
> itself. My testing has not be exhaustive however.
> > On Tue, Sep 12, 2017 at 11:15 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> > > I suspect it was during the force push. All the commits up to
> > > 11d2d6fd92acf9abc762c41e0f7b91c5acc89f4f -- in all the repos I listed
> > > including the "old/original" ones -- have the same hash. Thereafter
> > > differ. Look at the following comparison btw Lar's/my old clone and
> > what's
> > > currently in the Apache/gh repos.
> > >
> > > Notice:
> > > 1) that the only difference is in the name for the author/committer
> > > is missing.
> > > 2) If you look at the actual commit from SVN it includes the user
> > > https://svn.apache.org/viewvc?view=revision&revision=670801
> > >
> > > Not sure how this crept in, perhaps a bug in git that was exposed as
> > > of the force push?
> > >
> > > ----
> > > phunt@phunt-MBP13:~/dev/t/lars[branch-3.3]$ git show --format=raw
> > > 88a823c32dd080ae8a193948ba8915e9fa222e37