Git subtree command sustainability

Git subtree command sustainability

[Loic Fouray]

Hi,

I want use the git subtree split command on a new repo for splitting, extracting only a directory with its commits related from an upstream repo. It works !
But I would like to know if the subtree split command is sustainable or if you advise to use other tools (as git-filter-repo for exemple)? 

Thanks for your help
Loïc

Re: Git subtree command sustainability

[Elijah Newren]

On Tue, Nov 23, 2021 at 11:13 AM Loic Fouray <loic@yeplaa.net> wrote:
>
> Hi,
>
> I want use the git subtree split command on a new repo for splitting, extracting only a directory with its commits related from an upstream repo. It works !
> But I would like to know if the subtree split command is sustainable or if you advise to use other tools (as git-filter-repo for exemple)?
>
> Thanks for your help
> Loïc

Extracting a directory and its commits is a fairly simple kind of
rewrite.  If that's all you need, both tools can do it.  If
git-subtree works for you, that's great, and you don't need to switch
to a different tool.

If you're trying to do something a bit more complex, here are reasons
you might want to use one tool or the other:

- When rewriting history, commit IDs change.  git filter-repo will
rewrite commit messages to update references to (possibly abbreviated)
commit IDs to use the new commit IDs.  As far as I know, it's the only
history rewriting tool that does that; so if that's important to you,
using filter-repo may be beneficial.  But not all projects are
concerned with this; some repositories just don't have commit messages
that reference other commits.

- git-filter-repo allows much more complex rewrites (e.g. replacing
text in files while you are at it, stripping large blobs, using
mailmap to permanently change names, generic path manipulation,
inserting a commit, etc.), so if you also need to make other changes,
filter-repo is the tool you want.  git-subtree offers no other kind of
rewrite.

- git-filter-repo makes no effort to allow simultaneously working with
both the original and rewritten histories.  That kind of thing does
not mesh well with a generic history rewriting tool; you have to have
very specific types of rewrites to allow history to be reversible so
you can take information back to the original repo (in addition to
needing to track extra metadata).  However, git-subtree was written
precisely with a limited history rewrite in mind where this is
possible and provides tooling to assist you in working with both
histories and porting changes between the two.  If that's something
you want to do, git-subtree is the better tool for you.

- If you run into a scale where git-subtree doesn't work, but you do
want the simultaneous working with old-and-new histories abilities,
you may want to look into https://github.com/josh-project/josh.


Hope that helps,
Elijah