view hgext/git/TODO.md @ 44905:f330d6117a5b

relnotes: advertize the possibility to use rust

I think the rust work may have been mentioned in the release notes,
but if so only in passing, and not as an invitation to try it out.

I think the next version is a decent time to do this, because the rust
doesn't come with performance regressions AFAIK, speeds up status
noticeably when it applies, which is the case for most invocations of
status, and doesn't have the undesirable restriction of regex around
empty patterns anymore.

I am cheating a bit, because I'm giving numbers for `hg status` in
mozilla-central, but they have one hgignore pattern that uses
lookaround, ".vscode/(?!extensions\.json|tasks\.json", which I took
out as it would cause a fallback to python when unknown files are
requested. But it seems that they could express their hgignore
differently if they were so inclined.

Not sure if there are limitation other than linux-only that I am
not thinking of but would be worth mentioning upfront, to avoid
disappointing users?

Differential Revision: https://phab.mercurial-scm.org/D8604

Octopus Merge Support
=====================

This will be moderately complicated, as we'll need to synthesize phony
changeset entries to explode the octopus into "revisions" that only
have two parents each. For today, we can probably just do something like

    aaaaaaaaaaaaaaaaaaXX{20 bytes of exploded node's hex sha}

where XX is a counter (so we could have as many as 255 parents in a
git commit - more than I think we'd ever see.) That means that we can
install some check in this extension to disallow checking out or
otherwise interacting with the `aaaaaaaaaaaaaaaaaa` revisions.


Interface Creation
====================

We at least need an interface definition for `changelog` in core that
this extension can satisfy, and again for `basicstore`.


Reason About Locking
====================

We should spend some time thinking hard about locking, especially on
.git/index etc. We're probably adequately locking the _git_
repository, but may not have enough locking correctness in places
where hg does locking that git isn't aware of (notably the working
copy, which I believe Git does not lock.)