view hgext/git/TODO.md @ 51723:9367571fea21

cext: correct the argument handling of `b85encode()`

The type stub indicated that this argument is `Optional`, which implies None is
allowed.  I don't see in the documentation where that's the case for `i`[1], and
trying it in `hg debugshell` resulted in the method failing with a TypeError.  I
guess it was typed as an `int` argument because the `p` format unit wasn't added
until Python 3.3[2].

In any event, 2 clients in core (`pvec` and `obsolete`) call this with no
argument supplied, and `mdiff` calls it with True.  So I guess we've avoided the
None arg case, and when no arg is supplied, it defaults to the 0 initialization
of the `pad` variable in C.  Since the `p` format unit accepts both `int` and
None, as well as `bool`, I'm not bothering to bump the module version- this code
is more permissive than it was, in addition to being more correct.

Interestingly, when I first imported the `cext` and `pure` methods in the same
manner as the previous commit, it dropped the `Optional` part of the argument
type when generating `util.pyi`.  No idea why.

[1] https://docs.python.org/3/c-api/arg.html#numbers
[2] https://docs.python.org/3/c-api/arg.html#other-objects

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.)