SVG can use SMIL animation elements such as
<set> to create declarative animation/interactivity. This allows you to dynamically change attributes like position, opacity, fill and CSS class. These features seem very widely used, but would be handy for a self-contained diagram, for example a tabbed interface based on opacity.
The following demo uses the
<set> element to change fill colours base on
mouseover events, showing that events can target other elements by
<svg width="415" height="100" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <rect fill="#ff660099" x="0" y="0" width="200" height="100"> <set attributeName="fill" to="#ff009999" begin="click" dur="1s" /> <set attributeName="opacity" to="0.1" begin="rect2.mouseover" dur="1s" /> </rect> <text x="20" y="55" fill="#333">Click/tap to change colour</text> <rect id="rect2" fill="#ff660099" x="215" y="0" width="200" height="100"> </rect> <text x="225" y="55" fill="#333">Hover targets other rectangle</text> </svg>
Inkscape can also edit such SVGs without destroying overwriting the animation elements.
GitHub commit squashing — no need to rebase
I still occasionally get well-meaning advice from GitHub bystanders to rebase and squash my commits in pull requests. Ignore those folks — it's not necessary. Way back in 2016, GitHub introduced a pull request squash feature to give maintainers the discretion to squash a contribution into a single commit. Besides, overly-enthusiastic rebasing can cause problems for others following along with your work.
Pelican maintainer Justin Mayer wrote this in response to a piece of such advice:
(Bystander) As a general note, I would expect all the commits to be squashed into a single one, the upstream doesn't need your development history I think.
(Meyer) I'm not sure I agree. When formulated with thought and care, multiple commits can indeed be quite useful. Also, during feedback-and-change iterations, it can be useful to see what has changed in a PR over time, in which case cleaning up the commits can be done at the very end, right before merging.
(Me) I don't use GitHub a lot for collaboration myself, but I believe there's been a "merge and squash" button available to maintainers for a few years now for use at their discretion.
(Meyer) That is correct. If the commits aren't valuable on their own (e.g., if there are "fix-up" commits that add no value as separate commits), the maintainer can squash the commits if the contributor hasn't already done said clean-up.
GitLab, which I use a lot more day-to-day, has had a similar feature available for many years too. I don't use it regularly as I prefer to retain the full development history.
Reordering commits during git rebase
Reordering git commits during a
git rebase --interactive is as simple as
reordering the lines of text in the commit list that pops up in your editor.
Although I tend not to rebase aggressively, this reordering is handy to group
related changes together for easier review.