It's a bare repo and I didn't realize server-side reflogs were a
thing. Just ran "git config core.logallrefupdates true" in the repo on
the server which seems to be what I should do to enable that.
The server does know about B, it shows up when you do "git show B".
However "git branch --contains B" returns nothing.
The filesystem is ext4 on linux. It's on a virtual machine in our own
datacenter. It's not an NFS share or anything like that, there is
definitely only one server accessing the filesystem at a time.
Gitlab's update hook maintains an event log when any push event
happens, who pushed and which commits. The most recent time this
happened, the first push which was lost occured at 2014-03-24 19:04:51
and the one that overwrote it happened at 2014-03-24 19:05:04. That's
when the update hook ran, not necessarily when the user hit "git
push", but it is notable that it's 13 seconds apart which is a pretty
long time. We do run several hooks for checking coding syntax and
various other things so it's believable to me that the hooks would
take more than 13 seconds on occasion, but based on the testing I did
with the sleep hook it didn't seem like the hooks were actually the
On Mon, Mar 24, 2014 at 3:44 PM, Matthieu Moy
> Scott Sandler <scott.m.sand...@gmail.com> writes:
>> Both pushes are
>> determined to be fast-forwards and both succeed, but B' overwrites B
>> and B is no longer on origin/master. The server does have B in its
>> .git directory but the commit isn't on any branch.
> Is the reflog enabled on the server? If so, does it say anything about B
> and B'?
> What filesystem do you use on the server? Is there any kind of NFS, and
> if so are you sure that there's only one machine accessing the
> filesystem at the same time?
> Matthieu Moy
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html