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:52:50 -0500	[thread overview]
Message-ID: <8ad16219-2426-6127-b41d-bb3007a9b993@smartsoftwareinc.com> (raw)
In-Reply-To: <20200622204346.GP6531@camp.crustytoothpaste.net>

Using the steps from my original email for how I had the repository set 
up (any user authentication scheme works), clone 2 copies from that 
repository (call them A and B). Make, commit, and push a change in A. 
Then make, commit, and push a change in B (without first pulling). With 
the 1.8 client, B will prompt that you're out of date and need to 
update. With the 2.26 client, B's commit will be pushed and be forced.

Thanks for your help.

Michael

On 6/22/20 3:43 PM, brian m. carlson wrote:
> On 2020-06-22 at 20:30:06, 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.
> If you can provide a set of reproduction steps for this, I'd be happy to
> write a patch to fix it.  We should do the right thing for non-force
> pushes in both cases.
>
> I will say that overall, few people use the DAV-based protocol, since
> it's significantly less efficient than the smart protocol, so it doesn't
> surprise me that there may be bugs there.

  reply	other threads:[~2020-06-22 20:52 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
2020-06-22 20:31     ` Michael Ward
2020-06-22 20:43     ` brian m. carlson
2020-06-22 20:52       ` Michael Ward [this message]
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=8ad16219-2426-6127-b41d-bb3007a9b993@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.