git-subtree rewrite

Hi, Avery.

tl;dr:
  Do you object if I use the name git-subtree for my rewrite?

  I intend it to be forward compatible with existing git-subtree
  histories and existing command line invocations.

I've been looking into your git-subtree program. Thanks for it; it is definitely solving a very real problem reasonably well. [1] However, I think the existing implementation (in shell) and data model need some work.

I have done some experiments, with enough success that I have more or less decided to try to rewrite git-subtree.

I am intending to make my rewrite able to work with existing histories (ie, projects which have done git-subtree add and git-subtree merge). I intend to support the existing command line interface, although I may improve that later.

I am also hoping to be able to define the data model more formally.

The git maintainers and others on the git mailing list seem reasonably enthusiastic about all this. My nascent rewrite is a a standalone Rust package, and the plan would be for it to obsolete the shell script in git.git/contrib, but live outside the git project itself.

I would like to call my new program "git-subtree" and have it use (and extend) the exisitng `git-subtree-...:` metadata that `git-subtree add` puts into its generated commits.

Obviously there are compatibility, packaging, and deployment considerations, which I'm keeping in mind. I don't want to break anyone downstream. So I will proceed reasonably cautiously.

I hope this is all OK with you. If not, or if you have questions, please let me know, using reply-all to this email (so the mailing list gets a copy).

If I don't hear from you I will go ahead. The actual programming work is going to take a while so watch this space but not too closely :-).

Regards, Ian.

[1] See also my blog post
   Never use git submodules
   https://diziet.dreamwidth.org/14666.html