8000 A crisscross merge leads to losing changes · Issue #6369 · jj-vcs/jj · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

A crisscross merge leads to losing changes #6369

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
neongreen opened this issue Apr 18, 2025 · 3 comments
Open

A crisscross merge leads to losing changes #6369

neongreen opened this issue Apr 18, 2025 · 3 comments

Comments

@neongreen
Copy link
Contributor
neongreen commented Apr 18, 2025 •
edited
Loading

Description

Tested on jj 0.28.2.

Sequence of events:

  • commit A: changes ABC to XYZ
  • commit B: changes ABC to XYZ
  • commit C=merge(A,B): we still have XYZ here
  • commit D=merge(A,B): we still have XYZ here
  • commit E=merge(C,D): now we have ABC again!

See this log:

jj log -p -Tbuiltin_log_comfortable
@    p Emily 24 seconds ago 32f6c26a
├─╮  (empty) file.txt (no change)
│ │
│ ○    nw Emily 24 seconds ago 904b2dfe
│ ├─╮  file.txt s/original/modified
│ │ │
│ │ │  Added regular file merge1:
│ │ │      (empty)
○ │ │  no Emily 24 seconds ago git_head() 1a87c77b
╰─┬─╮  file.txt (no change)
  │ │
  │ │  Added regular file merge2:
  │ │      (empty)
  │ ○  nk Emily 24 seconds ago a45b96c8
  │ │  file.txt s/original/modified
  │ │
  │ │  Modified regular file file.txt:
  │ │     1    1: originalmodified
  ○ │  k Emily 24 seconds ago c74287d5
  ├─╯  file.txt original
  │
  │    Modified regular file file.txt:
  │       1    1: originalmodified
  ○  zt Emily 24 seconds ago 1f494f9b
  │  file.txt original again, but the commit is empty
  │
  │  Added regular file file.txt:
  │          1: original
  ◆  zz root() 00000000

Steps to Reproduce the Problem

jj git init --colocate .
jj b c init -r@; echo original > file.txt
jj new init; jj b c A -r@; echo modified > file.txt
jj new init; jj b c B -r@; echo modified > file.txt
jj new A B; jj b c C -r@
jj new A B; jj b c D -r@
jj new C D; jj b c E -r@

jj file show -rE file.txt

Expected Behavior

"modified"

Actual Behavior

"original"

Specifications

  • Platform: Linux, Windows
  • Version: 0.28.2
@martinvonz
Copy link
Member

As discussed on Discord, this is kind of working as intended. Revision C merges two revisions that both contain a abc->xyz diff. Since the state after the merge (i.e. the state in C) is xyz, it effectively discarded one abc->xyz diff. The same is true for D. So when E merges C and D, the result is that two abc->xyz diffs get discarded, which takes you back to the abc state.

@joyously
Copy link

this is kind of working as intended.

I guess you can explain it away, but surely the intention is faulty since merge is a combining operation, not subtracting.

@martinvonz
Copy link
Member

this is kind of working as intended.

I guess you can explain it away, but surely the intention is faulty since merge is a combining operation, not subtracting.

Sorry, I was unclear. I wasn't trying to explain it away. I was just explaining why it works the way it does.

We talked on Discord about how we should be able to fix it by resolving the intermediate results when doing the recursive merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@martinvonz @neongreen @joyously
0