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 are post-receive hooks that curl to notify external services like jenkins, and there is gitlab's update hook which just either allows or denies a push based on gitlab's own permissions check, and then updates a redis queue (https://github.com/gitlabhq/gitlab-shell/blob/master/lib/gitlab_update.rb). Am I absolutely positively sure that it's not a force push? I'm pretty confident they're not force pushing. This has happened now to 5 different pairs of developers using a variety of Git clients (Git bash, git cli on mac and linux, sourcetree) and most of them didn't even know what force push was until I asked them if they had done it. They're all using ssh URLs for the git remote, not http, in case that's relevant, and they showed me their git configurations and nothing looks amiss. After the first time it happened I also put a pre-receive hook in the repository to prevent force pushes to master, since I thought that's what had happened: while read OLDREV NEWREV REFNAME do if [ "$REFNAME" == "refs/heads/master" -a "$OLDREV" != $(git merge-base $OLDREV $NEWREV) ]; then echo "ERROR: It seems like you are trying to force-push on master." exit 1 fi done I did this so that people could still force push on other branches if they really wanted to (since many mentioned they do this on their remote branches sometimes). I'm under the impression this hook works properly since it rejects my attempted force pushes to master. On Mon, Mar 24, 2014 at 6:59 PM, Nasser Grainawi <nasser@xxxxxxxxxxxxxx> wrote: > On Mar 24, 2014, at 4:54 PM, Jeff King <peff@xxxxxxxx> 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 two users both have commits >>> based on commit A, call them B and B'. The user with commit B pushes >>> at about the same time as the user who pushes B'. 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. >> >> What version of git are you running on the server? Is it possible that >> there is a simultaneous process running `git pack-refs` (e.g., a `git >> gc` run by a cron job or similar)? > > `git gc --auto` could be getting triggered as well, so if you suspect > that you could set gc.auto=0 on the server side. > >> >> There were some race conditions fixed last year wherein git could see >> stale values of refs, but I do not think they could impact writing to a >> ref like this. When we take the lock on the ref, we always go straight >> to the filesystem, so the value we see is up-to-date. >> >> -Peff >> -- >> 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 > > -- > The Qualcomm Innovation Center, Inc. is a member of Code Aurora > Forum, hosted by The Linux Foundation > -- 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