Is there a way to automatically "clean" empty commits?

[BatmanAoD]

I seem to find myself with empty commits relatively frequently (probably largely because I'm still getting used to jj idioms).

Is there a way to globally squash all empty commits into their respective parents, or equivalently, abandon them (rebasing their children onto their parents)?

[martinvonz]

Try jj log -r '(~empty())..' to find empty commits that don't have non-empty descendants (or, to more directly match the revset, "commits that are not ancestors of non-empty commits"). If you want to git rid of those commits, just pass the same revset to jj abandon. (You may not want to squash them because that would rewrite their parents, which is probably not what you want if some of the parents exist on some remote.)

I'm also curious how you end up with the empty commits.

[BatmanAoD]

I'm happy to see branches deleted, I'm just uncomfortable with commits still reachable from the working copy being deleted. I use git fetch --prune far more often than git fetch, and I wish that it would delete local tracking branches as well (unless there are commits on the local branch that weren't on the last-seen version of the remote branch, I guess).

I'm possibly still confused about the jj fetch behavior. Is it only the state of the working copy that can cause a rebase, or can any arbitrary commit-sequence potentially be rebased if a branch points somewhere into its ancestor tree and is then deleted? That can't be right, can it?

[BatmanAoD]

...I guess a more general rule is: a branch is just a tag, so I don't ever expect deleting a branch to cause commits to be deleted, much less for new commits (the rebase sequence) to be created automatically. I would expect it to have exactly the same behavior as if I deleted a tag.

[martinvonz]

There are many things that fed into the current behavior:

• I copied many ideas from hg. One of them is anonymous branches/heads.
• I initially copied "changeset evolution" from hg. I later realized that first-class conflicts means that we can automatically rebase commits right away instead of having something like hg's explicit hg evolve command.
• When a commit has been obsoleted (e.g. hg prune),hg evolve will rebase descendants onto the parent. Similarly, jj's automatic rebasing will rebase descendants onto the parent when you jj abandon a commit
• If the commit was made obsolete on a remote, then hg pull (the git fetch-like thing) would propagate that locally, and a subsequent hg evolve would fill in the same was as if it had been obsoleted locally to start with. There's no native jj remote yet, but if there were, and a commit had been abandoned on the remote, I would like that to propagate to the local repo like it does with hg
• Git remotes don't have a concept of obsolete or hidden commits. Instead, they define anything that's reachable from a ref as visible. jj git fetch takes that definition and uses it for figuring out which commits have been "abandoned" (i.e. become unreachable) on the remote.

I hope that helps clarify the current behavior. I don't mean to say that we can't change it.

[necauqua]

As much as I love jj, this behavior is indeed strange - I just never fetched a branch deletion where locally I have child commits of that branch

Like, deleting a tip is fine, but abandoning (and thus rebasing children) the middle commit just doesn't make that much sense to me at all, it's just weird, almost like a bug, or a git brain thing

And yeah, currently in jj branches are literally lightweight tags that are only needed for git remote interop - me being fine with deletion of the tip is a git brain thing - and whoops, I just realised that just the tip also doesn't make much sense, I was thinking more about like a branch in git (ancestors upto the trunk?. not even well-defined in my head)

tl;dr I never realised this was a thing and I completely agree with the batman man

[BatmanAoD]

So, having finally run into this personally and found it to be exactly as bad as I feared (...I squash my PRs when I merge them, which exacerbated things; and this behavior isn't just on jj git fetch but on every command that imports from .git, including jj status), I think the big question that still remains in my mind is: if deleting a commit requires rebasing child commits, then by definition, that commit was reachable, so...why is it being deleted?

[ilyagr]

I hadn't even realized this was possible, but it apparently is.

Try jj log -r 'empty() ~ merges()'. If you like the result, you can jj abandon 'empty() ~ merges()'. If you include merges, there is a minor bug with abandon (#2482) that will mess up the topology of the repo a bit.

At the moment, I don't see a way to exclude commits with non-empty descriptions.

Update: Actually, @yuja implemented that as well.

jj log -r '(empty() ~ merges()) & description(exact:"")'

[martinvonz]

Good point about non-empty descriptions. You can use description(exact:"") to match commits with empty descriptions.

[BatmanAoD]

This also needs ~ root().

[ezzieyguywuf]

This also needs ~ root()

For my future lazy self here's the full incantation:

jj log -r '(empty() ~ merges()) & description(exact:"") ~ root()'