Replace uses of content_hash! with #[derive(ContentHash)]

[emesterhazy]

This is a pure refactor with no behavior changes.

[emesterhazy]

Not quite sure how to stack commits on GitHub... but the intention is to submit this change after the diffbase that implements the macro is submitted.

[thoughtpolice]

Not quite sure how to stack commits on GitHub... but the intention is to submit this change after the diffbase that implements the macro is submitted.

The way you did it just now is fine, though I think normally all of us just sorta "suck it up" and review every change on GitHub commit-by-commit. So you could split this into two PRs, or just one with two commits, depending on how you feel, I suppose.

[thoughtpolice]

Also, @sunshowers also has mentioned in Discord that she uses a version of https://github.com/getcord/spr with jj support that she added in, to do stacked diffs. Maybe it would be worth suggesting this to contributors for now. I'm not sure.

[martinvonz]

Not quite sure how to stack commits on GitHub... but the intention is to submit this change after the diffbase that implements the macro is submitted.

As Austin said, this way is fine. It allows one PR to get in before another. Putting closely related commits in a single PR makes it easier to review, though, because GitHub makes it easy to navigate the stack.

[sunshowers]

Also, @sunshowers also has mentioned in Discord that she uses a version of getcord/spr with jj support that she added in, to do stacked diffs. Maybe it would be worth suggesting this to contributors for now. I'm not sure.

An issue with this, as far as I know, is that spr requires that you can push branches to the upstream repo. That's because of the interaction between GitHub and spr -- the way stacks must be modeled (branches targeting other branches) requires that the target branch be part of the upstream repo.

This is not an issue with spr specifically -- it is inherent to how poorly GitHub deals with stacks. :(