Re: Git 2 force commits but Git 1 doesn't

[Michael Ward <mward@smartsoftwareinc.com>]

Whoops, 2.26.2 is the Fedora version. Not 2.27.2.

Michael

On 6/22/20 3:30 PM, Michael Ward wrote:
> Versions in use are 2.27.2 and 1.8.3.1. This behavior is seen with 
> regular pushes.
>
> I'll look into the http-backend functionality. If that will help 
> control that, we'll definitely want to use that instead. What 
> surprises me, though, is that even with DAV a 1.8 client appears to 
> work correctly in that it will warn the user that their push is about 
> to clobber the head, but 2.27 doesn't.
>
> Michael
>
> On 6/22/20 3:21 PM, brian m. carlson wrote:
>> On 2020-06-22 at 19:40:15, Michael Ward wrote:
>>> We have some repositories we are hosting here using Apache's DAV 
>>> module to
>>> handle remote connections.
>>>
>>> The repositories are created using the following:
>>>
>>> mkdir [reponame].git
>>> cd [reponame].git
>>> git --bare init
>>> git update-server-info
>>>
>>> Our Apache location directive is as follows:
>>>
>>> <Location /[reponame].git>
>>>          DAV on
>>>          AuthType Basic
>>>          AuthName "Git"
>>>          AuthBasicProvider ldap
>>>          AuthLDAPUrl [ldap server info]
>>>          <RequireAny>
>>>                  require [ldap filter]
>>>          </RequireAny>
>>> </Location>
>>>
>>> The repository config generates with the values in the core section 
>>> below,
>>> and we add the receive and advice sections:
>>>
>>> [core]
>>>          repositoryformatversion = 0
>>>          filemode = true
>>>          bare = true
>>> [receive]
>>>          denyNonFastForwards = true
>>>          denyDeletes = true
>>> [advice]
>>>          pushFetchFirst = true
>>>
>>> The odd behavior comes when we have git 1 vs git 2 clients 
>>> attempting to
>>> push in changes on the same branch. Git 1 clients will prompt the 
>>> user that
>>> they are out of date and need to pull. Git 2 clients don't and will 
>>> force
>>> push and overwrite the head revision. This occurs with either Git 1 
>>> or Git 2
>>> on the server.
>> Are you seeing this behavior when users are doing a force push, or just
>> a regular push?  I see that there exists code for the DAV-based protocol
>> to fail if a user attempts a regular push and is out of date, but I
>> haven't verified it works.
>>
>> If you're seeing this when users are doing a force push, then that's
>> expected.  The receive.* options have no effect here, since those
>> require an appropriate git process to run on the server, and you're
>> using the dumb (DAV-based) protocol, not the smart protocol. Therefore,
>> no git process runs on the server, so all the checking is done on the
>> client side and the client side allows force pushes with an appropriate
>> option.
>>
>> If you want to have more control over what's pushed, you'll need to use
>> the smart protocol instead, which is outlined in the git-http-backend
>> documentation.
>>
>> As a note, there are a lot of differences between Git 2.0.0 and the
>> latest version, Git 2.27.0, so it's probably best if you mention the
>> full version when reporting issues.  You haven't mentioned the specific
>> versions you're using, but it's possible if you're using the CentOS 6 or
>> 7 versions that they simply didn't support force pushing in this way.