All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ward <mward@smartsoftwareinc.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>, git@vger.kernel.org
Subject: Re: Git 2 force commits but Git 1 doesn't
Date: Mon, 22 Jun 2020 15:30:06 -0500	[thread overview]
Message-ID: <a42d038f-bf14-8f1a-927e-7488796e7710@smartsoftwareinc.com> (raw)
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:
> 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.

  reply	other threads:[~2020-06-22 20:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-22 19:40 Git 2 force commits but Git 1 doesn't Michael Ward
2020-06-22 20:21 ` brian m. carlson
2020-06-22 20:30   ` Michael Ward [this message]
2020-06-22 20:31     ` Michael Ward
2020-06-22 20:43     ` brian m. carlson
2020-06-22 20:52       ` Michael Ward
2020-06-22 21:09         ` brian m. carlson
2020-06-22 22:17           ` Michael Ward
2020-06-23  1:05             ` brian m. carlson
2020-06-23  8:59               ` René Scharfe
2020-06-23 15:30                 ` brian m. carlson
2020-06-23 16:42                   ` René Scharfe
2020-06-23 19:13                     ` brian m. carlson
2020-06-24 13:05                     ` René Scharfe
2020-06-23 20:21               ` [PATCH] http-push: ensure unforced pushes fail when data would be lost brian m. carlson
2020-06-23 21:28                 ` Eric Sunshine
2020-06-23 21:50                   ` brian m. carlson
2020-06-23 21:52                 ` [PATCH v2] " brian m. carlson
2020-06-23 22:41                   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a42d038f-bf14-8f1a-927e-7488796e7710@smartsoftwareinc.com \
    --to=mward@smartsoftwareinc.com \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.