Subject: git-remote-gcrypt: git push always behaves as if --force is given
Date: Sun, 01 Oct 2017 20:58:30 -0500
Package: git-remote-gcrypt
Version: 1.0.1-1
Severity: important
Here's a secnario -
I have repo A and repo B. Both have the same git-remote-gcrypt
repository named origin, and both begin with the same HEAD.
Now, make a commit on repo A and push it. Make a different commit
on repo B and run git push.
The expected result here is an error, and the usual way to handle
it would be to do a git pull followed by another push attempt.
Unfortunately, with git-remote-gcrypt, the push from repo B
silently clobbers the most recent commit made on repo A. A
subsequent pull from repo B will not pull down the changes
from repo A.
All is not *completely* lost; on repo A, a subsequent pull will
offer to merge the changes from repo B.
This is rather unfortunate for both collaboration with a workgroup
or even sharing files between multiple devices of one's own.
-- System Information:
Debian Release: 9.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages git-remote-gcrypt depends on:
ii git 1:2.11.0-3+deb9u1
ii gnupg 2.1.18-6
ii gnupg2 2.1.18-6
Versions of packages git-remote-gcrypt recommends:
ii curl 7.52.1-5
ii rsync 3.1.2-1
git-remote-gcrypt suggests no packages.
-- no debconf information
Information forwarded
to [email protected]: Bug#877464; Package git-remote-gcrypt.
(Mon, 02 Oct 2017 16:51:09 GMT) (full text, mbox, link).
Acknowledgement sent
to Sean Whitton <[email protected]>:
Extra info received and forwarded to list.
(Mon, 02 Oct 2017 16:51:09 GMT) (full text, mbox, link).
Dear John,
On Sun, Oct 01 2017, John Goerzen wrote:
> The expected result here is an error, and the usual way to handle it
> would be to do a git pull followed by another push attempt.
>
> Unfortunately, with git-remote-gcrypt, the push from repo B silently
> clobbers the most recent commit made on repo A. A subsequent pull
> from repo B will not pull down the changes from repo A.
Could you say which backend you were using when you saw this, please?
Possibly it affects all backends, but which were you able to test?
Thanks.
--
Sean Whitton
Acknowledgement sent
to John Goerzen <[email protected]>:
Extra info received and forwarded to list. Copy sent to Sean Whitton <[email protected]>.
(Mon, 02 Oct 2017 19:15:02 GMT) (full text, mbox, link).
Subject: Re: Bug#877464: git-remote-gcrypt: git push always behaves as if
--force is given
Date: Mon, 2 Oct 2017 13:31:50 -0500
On 10/02/2017 11:47 AM, Sean Whitton wrote:
>
> Could you say which backend you were using when you saw this, please?
> Possibly it affects all backends, but which were you able to test?
Hi Sean,
I tested it with both the rsync and the git:// backends and observed the
same behavior with both.
- John
Information forwarded
to [email protected]: Bug#877464; Package git-remote-gcrypt.
(Sun, 22 Oct 2017 19:27:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Sean Whitton <[email protected]>:
Extra info received and forwarded to list.
(Sun, 22 Oct 2017 19:27:03 GMT) (full text, mbox, link).
control: outlook -1 git-remote-gcrypt needs a test suite before this kind of bug can be fixed
Hello John,
On Mon, Oct 02 2017, John Goerzen wrote:
> On 10/02/2017 11:47 AM, Sean Whitton wrote:
>>
>> Could you say which backend you were using when you saw this, please?
>> Possibly it affects all backends, but which were you able to test?
> Hi Sean,
>
> I tested it with both the rsync and the git:// backends and observed
> the same behavior with both.
Thank you again for testing.
Fixing this bug is going to require substantial refactoring. I am
loathe to do that until git-remote-gcrypt has a test suite, so that I
can be sure existing functionality does not break.
I hope to be able to sit down and write such a test suite at some point
during the next year.
--
Sean Whitton
I was implementing another gitremote-helper today and ran into what I
think is the same problem. Since I've worked around the problem in my
gitremote-helper successfully, I wanted to share what I've learned in
case it can help git-remote-gcrypt.
When git push is run, for a non-forced push, it asks the
gitremote-helper program for "list for-push". It then sends a "push" to
it. And only after that does it go compare the list of refs it got with
the list of refs it has asked to be pushed, and notice if the push would
overwrite a ref. At that point, git pull will complain that refs were
not able to be pushed. But actually nothing stopped the gitremote-helper
from doing a push that overwrote a ref, effectively a force push.
I think this is a bug in git. I can't imagine why it behaves this way.
It requires that every gitremote-helper program effectively replicate
git's own detection of a disallowed push, in order to reject the
"push" with "error $ref"
It is certainly possible for a gitremote-helper program to do that
though. What I did is, when git runs "list for-push", I remember the
refs that are on the remote. Then when git runs "push $src:$dst",
(but not when it's a "+$src" forced push), I compare the sha of $src
with the old ref I saw on the remote. If the shas are different, I
check `git log --oneline $old..$src` -- if this outputs nothing, then
history is not advancing and it refuses to push that ref, and
reports the error to git.
--
see shy jo
Information forwarded
to [email protected]: Bug#877464; Package git-remote-gcrypt.
(Sat, 27 Apr 2024 09:18:09 GMT) (full text, mbox, link).
Acknowledgement sent
to Sean Whitton <[email protected]>:
Extra info received and forwarded to list.
(Sat, 27 Apr 2024 09:18:09 GMT) (full text, mbox, link).
Joey Hess wrote:
> with the old ref I saw on the remote. If the shas are different, I
> check `git log --oneline $old..$src` -- if this outputs nothing, then
> history is not advancing and it refuses to push that ref, and
> reports the error to git.
That's not quite right, because git log outputs commits when the two
refs are diverged but share a common ancestor.
I think the best way to detect it is
git merge-base --ancestor $old $src
which will exit nonzero on a non-fast-forward.
--
see shy jo
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.