Re: Git 2 force commits but Git 1 doesn't
- From
- Michael Ward <mward@smartsoftwareinc.com>
- Date
- Jun 22, 2020, 20:30 UTC
- Message-ID
- <a42d038f-bf14-8f1a-927e-7488796e7710@smartsoftwareinc.com>
- In-Reply-To
- <20200622202122.GO6531@camp.crustytoothpaste.net>
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:
Show 64 quoted lines
> 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.