Does this work with git-subtree?

Will this action work with subdirectories already pushed (and rejoined using --rejoin) to other repos using git subtree split/push? I have an existing monorepo with subdirs that have their own subtree-maintained repositories. But I want to be sure that this action would maintain the history as created by git-subtree.

[jasonkarns]

Thanks for the discussion! I’m going to close this for now, since it seems that generally the use cases don’t align exactly. It would be cool to see an implementation that allowed users to “opt-in” to 100% subtree compatible usage. But I suspect the cost/benefit doesn’t make the feature quite worth it.

[jasonkarns]

So notably, there’s no guarantee that the files people are interested in pushing are actually checked-in to git, so using git-subtree wouldn’t work for all use-cases.

👍 that makes sense

i’ve previously used submodules rather than git-subtree, though i can see the appeal of subtree over submodules here.

Yep, subtree is a bit simpler for many of the similar use-cases. The biggest benefit being that cloning a repo that uses subtrees doesn’t require any special commands or options (like recursing). The subtree directories are regular old directories.

(A feature that’s lost with subtree is that commits between the subdir-containing-monorepo and the subdir-as-root-repo have different shas, because pushing/pulling between them essentially re-plays commits. If having identical shas is important, then submodules are necessary.)

I’ll have to give it some thought, i’m not sure whether creating an action really provides much benefit over specifying the subtree commands directly in an actions file like you have.

Yep, I think the primary benefit would just be a more declarative configuration. A single-line “uses: action” declaration is more clear than a few lines of obscure and interpolated shell commands 😸 . But I agree, the benefit is slight.

how does the auth work for your linked workflow?

The checkout action (as of v2), persists the auth token into the local git configuration. So the repo token configured here is the same one used for all subsequent git operations. Instead of using the default generated token (which has read access to its “own” repo) we use a token that has write access on the remotes.