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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux