> 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 mast
On Tue, Mar 25, 2014 at 10:57 AM, Jeff King 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 don't
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 se
(please, don't top-post on this list)
Scott Sandler 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 really sure, you also h
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}: pus
Scott Sandler 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
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 ar
On Mar 24, 2014, at 4:54 PM, Jeff King 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 is that
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 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
Matthieu Moy 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 ext4, nothing exotic, so
Scott Sandler 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 about B, it shows up w
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 PM,
On Mon, Mar 24, 2014 at 8:18 PM, Scott Sandler
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 expected
> 61b79b6d35
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
Scott Sandler 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 anythin
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 bot
17 matches
Mail list logo
