Issues when working with git rebase workflow

[bemyak]

Hi! I'm enjoying jj and use it daily for most of my projects (except the ones heavily relying on submodules and LFS). However, I noticed some issues when working with rebase workflow on GitHub.

After a PR is rebased and remote branch is deleted, jj git fetch doesn't abandon local commits, even though I have git.abandon-unreachable-commits undefined (so it should be true). This creates a lot of noise in jj log, which becomes hard to read.

The local branch is deleted though (only its name, not commits), so it's impossible to do something like ::old-branch ~ ::master to get rid of it, I have to find the point where the branch was created and do jj abandon abcd::

The last and the most annoying issue: after cleaning a dead branch as described above, jj log (with default settings) shows the merged commits as ◌ (elided revisions) on the main branch, so I can't see them directly and have to do jj log -r "all()".

Am I doing something wrong here? Is there a nicer way to get rid of remote rebased commits and still see them with default jj log settings?

[yuja]

After a PR is rebased and remote branch is deleted, jj git fetch doesn't abandon local commits, even though I have git.abandon-unreachable-commits undefined (so it should be true). This creates a lot of noise in jj log, which becomes hard to read.

The local branch is deleted though (only its name, not commits)

If your repo is colocated, make sure that your local commits aren't checked out. Commits referred by unrelated refs including HEAD@git won't be abandoned. I'm not sure if the current behavior is correct, but that's how unreachable commits are deletected as of now.

[arxanas]

Also be sure to check all of your worktrees for that repo; sometimes I have commits checked out in other worktrees that I forgot about.

[bemyak]

Thanks, @yuja, it worked! After switching to jj, I've stopped thinking about where my HEAD is, because it enables me to edit the commit tree without actually checking out anything. Well, looks like I'll have to be extra careful (i.e., run jj new -r main) when interacting with Git 😅

The issue persist however if there are other branches on top of the merged branch. I have to find where the deleted branch has ended, and rebase the rest on top of the new master head.

Is it feasible to make JJ aware of such rebases (with branch deletion)?
I would like it to update change sets to point to the new commits from the main branch, not just create new change sets alongside with the old ones. This way all descendant branches will be updated as well.

I understand it's a "special case" feature request, but I believe it pretty popular.
Hope I'm making any sense here.

[yuja]

looks like I'll have to be extra careful (i.e., run jj new -r main) when interacting with Git 😅

Yeah, the current behavior is inconvenient, and might be better to exclude HEAD@git.

The issue persist however if there are other branches on top of the merged branch. I have to find where the deleted branch has ended, and rebase the rest on top of the new master head.

Perhaps, jj sync will implement a better abandoning/rebasing strategy, but I have no idea how that will be implemented.

#1039