Bug#877464: git-remote-gcrypt: git push always behaves as if --force is given

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#877464: git-remote-gcrypt: git push always behaves as if --force is given

John Goerzen-3
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

Reply | Threaded
Open this post in threaded view
|

Bug#877464: git-remote-gcrypt: git push always behaves as if --force is given

Sean Whitton
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

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#877464: git-remote-gcrypt: git push always behaves as if --force is given

John Goerzen-3

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

Reply | Threaded
Open this post in threaded view
|

Bug#877464: git-remote-gcrypt: git push always behaves as if --force is given

Sean Whitton
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

signature.asc (847 bytes) Download Attachment