brz push deletes commits in the git repo when there is a conflict

Bug #1873609 reported by Juan Francisco Cantero Hurtado on 2020-04-18
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Breezy
Critical
Jelmer Vernooij
3.0
Critical
Jelmer Vernooij

Bug Description

Steps to reproduce the bug:

- Create a new git repo in github with one text file and at least one commit.

- Open two terminals. In the first terminal use git to clone the repo, in the secondary terminal use brz branch git+ssh://whatever with the same repo.

- In the git terminal, modify the first line in the text file, commit the change and run git push.

- In the breezy terminal, modify the same line (with different content) in the same file, commit the change and run brz push. You will see something like "Pushed up to revision 2" with no error.

- In the git terminal, run git pull. It will show something like " + f3b6f48...39c9e78 master -> origin/master (forced update)". Your git commit is not in the remote git repo anymore.

Breezy shouldn't use push force without asking the user first or showing an error when there is a conflict.

Jelmer Vernooij (jelmer) on 2020-04-19
Changed in brz:
status: New → Triaged
importance: Undecided → Critical
milestone: none → 3.1.0
assignee: nobody → Jelmer Vernooij (jelmer)
Aaron Bentley (abentley) wrote :

I don't see evidence this deletes the commit. It appears to only change the branch tip. If the commit has been deleted, "git show $COMMIT" will report "bad object".

I've tested it again and the commit is deleted in the remote repo. You still have the local commit in the git repo but if you clone the repo again, it will not contain the deleted commit. I checked the reflog of the old and the new git repo.

Jelmer Vernooij (jelmer) wrote :

I think the bug report means that brz changes the ref to a commit that does not have the previous value in its ancestry - without actually removing anything from the object store. In the git world, the server doesn't check for ancestry - it's up to the client.

Jelmer Vernooij (jelmer) wrote :

Which version of Breezy were you using?

Jelmer Vernooij (jelmer) wrote :

I can reproduce this with Breezy 3.0 but not with the 3.1 branch.

Changed in brz:
status: Triaged → Fix Released
Jelmer Vernooij (jelmer) wrote :

We should see if we can backport this to the 3.0 branch. I'm not sure which change exactly fixed this, though.

The Arch Linux package (3.0.2.3). They're using the github tag with the commit aa1875e6a279e8c3eb9f86e143193d4967358207.

Jelmer Vernooij (jelmer) wrote :

Yeah, that's a version that still has the bug.

Also, they're using a Git commit for the Debian package? That seems rather odd.

Jelmer Vernooij (jelmer) wrote :

Yes, that's what I mean. The commit that the arch package is using points at a *debian* package in the Breezy repository. See https://github.com/breezy-team/breezy/commit/aa1875e6a279e8c3eb9f86e143193d4967358207

It may well work for Arch, but it will contain some Debian-specific changes and Debian packaging metadata.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers