This finally happened again. Here's what the reflog looks like:
2805f68 master@{0}: push
96eebc0 master@{1}: push
75bd4a6 master@{2}: push
abc30da master@{3}: push
eba874f master@{4}: push
10981e7 master@{5}: push
76b3957 master@{6}: push
2e3ea06 master@{7}: push
9d4e778 master@{8}:
On Tue, Mar 25, 2014 at 10:57 AM, Jeff King p...@peff.net wrote:
On Tue, Mar 25, 2014 at 09:45:20AM -0400, Scott Sandler wrote:
Version of git on the server? git version 1.8.3-rc0
There was significant work done between v1.8.3 and v1.8.4 on handling
races in the ref code. As I said before, I
Version of git on the server? git version 1.8.3-rc0
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. There are pre-receive hooks that either reject a push or
don't based on some checks, there
Scott Sandler scott.m.sand...@gmail.com 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
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}:
(please, don't top-post on this list)
Scott Sandler scott.m.sand...@gmail.com writes:
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.
To be
On Tue, Mar 25, 2014 at 09:45:20AM -0400, Scott Sandler wrote:
Version of git on the server? git version 1.8.3-rc0
There was significant work done between v1.8.3 and v1.8.4 on handling
races in the ref code. As I said before, I don't think the symptoms you
are describing are anything we have
Hi folks,
I run a private Git repository (using Gitlab) with about 200 users
doing about 100 pushes per day.
I've noticed that a few times in the past several weeks, we've had
events where pushes have been lost when two people pushed at just
about the same time. The scenario is that two users
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
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
On Mon, Mar 24, 2014 at 8:18 PM, Scott Sandler
scott.m.sand...@gmail.com wrote:
I run a private Git repository (using Gitlab) with about 200 users
doing about 100 pushes per day.
Ditto but about 2x those numbers.
error: Ref refs/heads/master is at
4584c1f34e07cea2df6abc8e0d407fe016017130 but
Right. Receiving that error is what happens during my testing with a
hook that sleeps for 60s, and that outcome makes sense. But whatever
is occurring in production must be different, since both users see
successful pushes with the first one just being overwritten.
On Mon, Mar 24, 2014 at 5:16
Scott Sandler scott.m.sand...@gmail.com writes:
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.
That should be it, yes.
The server does know
Matthieu Moy matthieu@grenoble-inp.fr writes:
What you describe really looks like a force-push, or a hook doing a ref
update (e.g. a hook on a dev branch that updates master if the code
passes tests or so).
... or a filesystem that is broken. But I thought this is just a
plain-vanilla
On Mon, Mar 24, 2014 at 10:16:52PM +0100, Ævar Arnfjörð Bjarmason wrote:
error: Ref refs/heads/master is at
4584c1f34e07cea2df6abc8e0d407fe016017130 but expected
61b79b6d35b066d054fb3deab550f1c51598cf5f
remote: error: failed to lock refs/heads/master
I also see this error once in a
On Mon, Mar 24, 2014 at 03:18:14PM -0400, Scott Sandler wrote:
I've noticed that a few times in the past several weeks, we've had
events where pushes have been lost when two people pushed at just
about the same time. The scenario is that two users both have commits
based on commit A, call
On Mar 24, 2014, at 4:54 PM, Jeff King p...@peff.net wrote:
On Mon, Mar 24, 2014 at 03:18:14PM -0400, Scott Sandler wrote:
I've noticed that a few times in the past several weeks, we've had
events where pushes have been lost when two people pushed at just
about the same time. The scenario
17 matches
Mail list logo
