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 <nas...@codeaurora.org> wrote:
> 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 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 majord...@vger.kernel.org
>> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
