I'm definitely open to the possibility there's a problem with my
setup. I've got the reflog on now and will check what that looks like
next time the issue happens. So far it looks like you described:
b2b202d master@{0}: push
7c01312 master@{1}: push
3635312 master@{2}: push
aea29bf master@{3}: push
8bfe464 master@{4}: push
fb35676 master@{5}: push
267114e master@{6}: push
2b5c822 master@{7}: push
9d7206f master@{8}: push
8fbeaf9 master@{9}: push
I'd like to see it happen again under these conditions and get that
information, then enable receive.denyNonFastForwards explicitly just
to be sure it's not force pushes, and see if it still happens. If
anyone has other ideas of things to look into or test, let me know.
Thanks,
Scott
On Tue, Mar 25, 2014 at 10:03 AM, Matthieu Moy
<Matthieu.Moy@xxxxxxxxxxxxxxx> wrote:
> Scott Sandler <scott.m.sandler@xxxxxxxxx> writes:
>
>> Is there a hook or cron job that updates or gcs this repository or any
>> refs? No. No cron jobs touching the repo at all, and all the hooks are
>> read-only.
>
> If you activated the reflog, you can double-check that. Running git
> reflog on the server should give you something like this:
>
> $ git reflog show master
> bf40764 (HEAD, master) master@{0}: push
> 2c4fc6d master@{1}: push
> e72211a master@{2}: push
> ...
>
> It should be possible to check the reflog for non-fast forward. I don't
> find an obvious way, but a script going through the sha1 list and
> checking that each line is an ancestor of the previous should be easy.
>
> I can't exclude the hypothesis of a bug in Git, but my feeling is that
> there's an issue with your setup.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html