I am going to take a stab at this (thanks again, @martinvonz, for the recommendation).

My usual progress disclaimer: family + full time job = 🐌

Maybe you can extract some bits from #3142

Oh, I wasn't aware that there is already an open PR for this.

@julienvincent, do you want to continue working on #3142?
I am happy to pick another issue instead.

@pylbrecht Please go ahead - I was planning on coming back to this at some point but I don't think I'm going to get a chance any time soon.

Oh, I wasn't aware that there is already an open PR for this.

Sorry, I had forgotten that we had this pending PR. Thanks for pointing it you, @yuja.

Heartbeat: I am still digging around the linked issues and PRs to build up context.

It looks like jj sign needs to be built on top of #3141, as it implements displaying commit signatures. Without it we do not have anything in stdout to assert against in CLI tests.

@julienvincent, I suppose you will not be able to work on #3141 any time soon either?

I suppose you mean #3141? I might be able to pick it up again on a weekend, but I wouldn't be able to commit very hard to it right now.

If you want to pick up work I don't have any particular attachments to it :)

Oh yeah, I meant #3141 (fixed the typo in the original comment).

I might be able to pick it up again on a weekend, but I wouldn't be able to commit very hard to it right now.

If you want to pick up work I don't have any particular attachments to it :)

Well, my first steps would be to take your changes, understand them, and eventually add whatever seems to be missing to start working on #4747. While there is a great chance it will take me as long (or even longer) as you to finish that job,
I would still give it a try, for the sake of learning.

I don't know if I should make a different issue for this or just leave a comment here, but I think the nicest workflow (for me, anyway) would be to sign commits automatically on push. i.e. I don't necessarily want to unlock my GPG key every time jj makes a snapshot, but I probably do want to sign anything that I push to a remote without having to manually run a sign command.

Agreed, batch signing should be a pre‐publish thing, like other clean‐up/linting hooks. (We were just discussing this on the Discord today.)

As I am currently banging my head against the wall, I would like to reach out to any jj veterans (or anyone with experience really) for help.

I am trying to port 9eaea83 to the current code base (the code seems to have changed quite a bit over the past months).

We want to display a hint, if any commit signatures were dropped during a rebase. Ideally we would like to store the "this rebase dropped a signature" bit in a central place, from which we can retrieve it whenever we need it (e.g. in CLI commands to display a hint if we dropped any signatures).
However, I failed to find a good place for it, as we seem to use several different functions in CLI commands for rewriting commits (transform_descendants(), rebase_descendants(), reparent_descendants(), etc.).

I started off by introducing RebaseCounts as done in #3141 and returning that from rebase_descendants() first; then from reparent_descendants(). But when I reached the first CLI command using transform_descendants() instead, I started doubting if this is the way to go. Looking at cli/src/commands/rebase.rs solidified my doubts, so I felt it's time to reach out.

Being new to the code base (and new to VCS internals in general), I am wondering if this is just cumbersome to solve and I have to bite the bullet, or if I am missing something that will make this simpler.

Any thoughts or suggestions would be much appreciated!

I was going to say that we can do that in report_repo_changes() here: https://github.com/martinvonz/jj/blob/0de36918e4c020e0e54816f29c47cb57cc9cfbf5/cli/src/cli_util.rs#L2032-L2038

However, as the comment there says, there may be millions of new commits added to the repo, so it can be very expensive to check all of them. It's probably better to go through MutableRepo::parent_mapping to find the rewritten commits: https://github.com/martinvonz/jj/blob/0de36918e4c020e0e54816f29c47cb57cc9cfbf5/lib/src/repo.rs#L870

However, we currently clear that map after using it. I don't think we should have to clear. I pushed main...push-rmnzxqzrwxwp to show what I mean, but I'm not at all confident that that's actually safe. I'll need to think more about it later.

I don't know if I should make a different issue for this or just leave a comment here, but I think the nicest workflow (for me, anyway) would be to sign commits automatically on push. i.e. I don't necessarily want to unlock my GPG key every time jj makes a snapshot, but I probably do want to sign anything that I push to a remote without having to manually run a sign command.

I quite like this approach as well, and I've created a PR adding a git.sign-on-push configuration option which does this that I've been using locally to push commits without having to sign them all the time (#5164). I think this doesn't replace an explicit jj sign command, but could be an alternative/accompaniment. (It currently depends on some commits from #4853 to add some basic tests.)

With #4853 merged, I am now focusing on getting #4747 out the door.