Removing a git tag abandons commits in jj

[jacg]

It seems that removing a git tag causes jj to abandon any commits that were previously reachable from that tag, even if they are still reachable from visible heads in jj. Here's a quick demonstration:

# The following was observed in version 0.29.0
jj -version

# Create a fresh git-colocated repo
jj git init --colocate demo
cd demo

# Create some commits
for i in {1..3}; do
  echo line $i >> file && jj commit -m "line $i"
done

# Place a git tag on the last one
git tag the-tag

# Create more commits on top of the tagged one
for i in {1..3}; do
  echo line $i >> file && jj commit -m "line $i"
done

# Remove the tag ...
git tag -d the-tag
# ... this abandons all the commits that used to be reachable from the tag

These commits still are/should-be reachable from their visible, unabandoned commits in the jj repo, so they should not be abandoned. Abandoning them makes a complete mess of the repo, and gives the impression that data have been irretrievably lost!

However, if no commits are created on top of the tagged one, before the tag is removed, then nothing is abandoned.

# Create a fresh git-colocated repo
jj git init --colocate demo-2
cd demo-2

# Create some commits
for i in {1..6}; do
  echo line $i >> file && jj commit -m "line $i"
done

# Place a git tag on the last one
git tag the-tag @~~~

# Remove the tag before making any jj commits on top ...
git tag -d the-tag
# ... this time the commits are NOT abandoned

Bug or feature?

[yuja]

It's working as intended. The problem is that there's no native support for creation/deletion of tags. See #6325.

[jacg]

So, feature, it would seem. Can you help me understand why anyone would ever want this? [So far, jj has only ever surprised me in good ways (and it has done so many times), but this was a very nasty surprise, especially as the usually-reliable op restore is helpless against it!]

At least

[git]
abandon-unreachable-commits = false

exists, and seems to switch to (in my mind) sane behaviour.

(I need to look into the meaning of the word 'imported' as used in various places in #6325, and how importing things results in them being abandoned. I guess it's a bit like git add sometimes removing files.)

[yuja]

Always treat @- and @ i.e. the working directory as reachable.

Just FYI, we had this behavior in old jj versions, but it was inconvenient and seemed inconsistent because jj git fetch doesn't abandon old branch if the branch happened to be ancestor of @.

[jacg]

We're supposed to rebase WORK off of BASE and onto BASE's parent. Did you see WORK getting abandoned instead?

There are two issues here:

1. It's not that WORK gets abandoned: BASE gets abandoned, leaving WORK meaningless. If BASE contained the creation of 100 files, each containing 10kLOC and WORK adds a single line to one of them, then I'm left with a conflict adding a single line to a non-existent file. No trace of that file's 10k lines of previous content and no trace of the other 99 files ever having existed. jj has just made 1 million lines that made WORK meaningful, disappear (apparently) without trace. This is INJURY.
2. This abandonment of BASE only happens if there is some WORK (i.e. when I'm likely to care about preserving BASE) but does not happen when there is no WORK (i.e. when I'm likely not to care about BASE). This is INSULT.

In trying to create a runnable demo of these observations, after setting abandon-unreachable-commits = true for the sake of the demo, I inadvertently ran the script in a real repo. I've now 'lost'[1] tons of real work, and the tricks I've thus far been using to get it back are not working. This is stressing me out and wasting lots of my time. This 'feature' is evil!

Maybe there are use cases for this, but SURELY any behaviour which makes valuable data disappear should not be the default.

It makes me wonder how many other such gems lie in wait, and significantly reduces my inclination to recommend jj to others. An inclination which was very strong until this discovery. Until now I had a strong feeling that the jj developers can be trusted to make sound decisions. That belief has been severely shaken.

[1] Edit: I trust that I can recover it, eventually (and already have, at the time of this edit), but for a significant proportion of those to whom I would be recommending jj, in practice, this work is irretrievably lost.

[jennings]

In trying to create a runnable demo of these observations, after setting abandon-unreachable-commits = true for the sake of the demo, I inadvertently ran the script in a real repo. I've now 'lost'[1] tons of real work, and the tricks I've thus far been using to get it back are not working. This is stressing me out and wasting lots of my time.

1. Find a commit ID from before the commits were abandoned. You can use jj evolog to see predecessors of a given change, or use jj op log and jj log --at-op ID to see the repo as it existed previously.
2. jj new COMMIT_ID

This will make all of the abandoned commits visible again.

[bnjmnt4n]

This abandonment of BASE only happens if there is some WORK (i.e. when I'm likely to care about preserving BASE) but does not happen when there is no WORK (i.e. when I'm likely not to care about BASE).

For reference, this isn't true. Any commits referenced by a newly deleted tag which are now unreachable will be abandoned. The reason for this misconception is that in your second example, you're running the two git tag commands sequentially without any jj commands in between. Jujutsu will not know that there was any changes in the Git repository since the tag was added and removed before it imports from the repository again. If you add a jj command in between the two git tag commands, the behavior should be consistent (in that all unreachable commits will be abandoned).

[tim-janik]

I just ran into this without the tag being base, but keeping a sibling branch alive.
Deleting the tag deleted the sibling branch and much of the base of @.

Any commits referenced by a newly deleted tag which are now unreachable will be abandoned.

Yeah, exactly this. Paired with not considering @- reachable (which still boggles my mind) means an entire base branch that @ is based on can be lost.

To verify, here are my steps, create commits for base, twig, dev.
Then tag twig + delete tag and all of base is lost:

for i in {1..3}; do date >> file && jj commit -m "BASE-$i" ; done
for i in {1..3}; do date >> file && jj commit -m "TWIG-$i" ; done
jj new @---- # start development on last BASE
for i in {1..3}; do date >> file && jj commit -m "DEV-$i" ; done
git tag twig-3 $(jj log --no-graph -T commit_id -r 'description(TWIG-3)') && jj st
git tag -d twig-3 && jj st

Just to be sure, is this really the intended behavior of JJ (apart from undo not working), or is there some facet of a bug at play at least in this scenario?