README: replace outdated claim about lacking git blame support

README.md

@@ -32,7 +32,7 @@ experienced, working on brand new projects alone, or large scale software
 projects with large histories and teams.
 
 Jujutsu is unlike most other systems, because internally it abstracts the user
-interface and version control algorithms from the *storage systems* used to
+interface and version control algorithms from the _storage systems_ used to
 serve your content. This allows it to serve as a VCS with many possible physical
 backends, that may have their own data or networking models—like [Mercurial] or
 [Breezy], or hybrid systems like Google's cloud-based design, [Piper/CitC].
@@ -83,7 +83,7 @@ And it adds several innovative, useful features of its own:
 
 - **Operation log & undo**: Jujutsu records every operation that is performed on the
   repository, from commits, to pulls, to pushes. This makes debugging problems like
-  "what just happened?" or "how did I end up here?" easier, *especially* when
+  "what just happened?" or "how did I end up here?" easier, _especially_ when
   you're helping your coworker answer those questions about their repository!
   And because everything is recorded, you can undo that mistake you just made
   with ease. Version control has finally entered [the 1960s][undo-history]!
@@ -93,7 +93,7 @@ And it adds several innovative, useful features of its own:
   makes "patch-based" workflows a breeze. If you resolve a conflict in a commit,
   the _resolution_ of that conflict is also propagated through descendants as
   well. In effect, this is a completely transparent version of `git rebase
-  --update-refs` combined with `git rerere`, supported by design.
+--update-refs` combined with `git rerere`, supported by design.
 
 > [!WARNING]
 > The following features are available for use, but experimental; they may have
@@ -105,14 +105,14 @@ And it adds several innovative, useful features of its own:
 
   The fundamental problem with using filesystems like Dropbox and backup tools
   like `rsync` on your typical Git/Mercurial repositories is that they rely
-  on *local filesystem operations* being atomic, serialized, and non-concurrent
+  on _local filesystem operations_ being atomic, serialized, and non-concurrent
   with respect to other reads and writes—which is _not_ true when operating on
   distributed file systems, or when operations like concurrent file copies (for
   backup) happen while lock files are being held.
 
   Jujutsu is instead designed to be [safe under concurrent scenarios][conc-safety];
   simply using rsync or Dropbox and then using that resulting repository
-  should never result in a repository in a *corrupt state*. The worst that
+  should never result in a repository in a _corrupt state_. The worst that
   _should_ happen is that it will expose conflicts between the local and remote
   state, leaving you to resolve them.
 
@@ -132,9 +132,10 @@ send an IRC message to [`#jujutsu` on Libera
 Chat](https://web.libera.chat/?channel=#jujutsu). The developers monitor all of
 these channels[^bridge].
 
-[^bridge]: To be more precise, the `#jujutsu` Libera IRC channel is bridged to
-one of the channels on jj's Discord. Some of the developers stay on Discord and
-use the bridge to follow IRC.
+[^bridge]:
+    To be more precise, the `#jujutsu` Libera IRC channel is bridged to
+    one of the channels on jj's Discord. Some of the developers stay on Discord and
+    use the bridge to follow IRC.
 
 ### News and Updates 📣
 
@@ -208,9 +209,10 @@ uses the [libgit2](https://libgit2.org/) C library and the
 
 [backends]: https://jj-vcs.github.io/jj/latest/glossary#backend
 
-[^native-backend]: At this time, there's practically no reason to use the native
-backend. The backend exists mainly to make sure that it's possible to eventually
-add functionality that cannot easily be added to the Git backend.
+[^native-backend]:
+    At this time, there's practically no reason to use the native
+    backend. The backend exists mainly to make sure that it's possible to eventually
+    add functionality that cannot easily be added to the Git backend.
 
 The Git backend is fully featured and maintained, and allows you to use Jujutsu
 with any Git remote. The commits you create will look like regular Git commits.
@@ -296,8 +298,8 @@ commit to any other commit using `jj squash -i --from X --into Y`.
 
 ## Status
 
-The tool is fairly feature-complete, but some important features like (the
-equivalent of) `git blame` are not yet supported. There
+The tool is fairly feature-complete, but some important features like support
+for Git submodules are not yet completed. There
 are also several performance bugs. It's likely that workflows and setups
 different from what the core developers use are not well supported, e.g. there
 is no native support for email-based workflows.
@@ -307,7 +309,7 @@ have almost exclusively used `jj` to develop the project itself since early
 January 2021. I haven't had to re-clone from source (I don't think I've even had
 to restore from backup).
 
-There *will* be changes to workflows and backward-incompatible changes to the
+There _will_ be changes to workflows and backward-incompatible changes to the
 on-disk formats before version 1.0.0. Even the binary's name may change (i.e.
 away from `jj`). For any format changes, we'll try to implement transparent
 upgrades (as we've done with recent changes), or provide upgrade commands or