How can one eliminate subtree commit history due to a remote tracking branch?

[Eric Anderson]

Too late I realized that this way of adding a subtree...

git remote add shared remoteRepoWithSharedCode.git
git subtree add --squash --prefix=myShared shared master

does not have the same effect as this...

git subtree add --squash --prefix=myShared remoteRepoWithSharedCode.git master

The former does much the same as the latter, but in the former method the fetch done by subtree add also creates an additional "[new branch]" that is a remote tracking branch. As a consequence, the first method also mixes in the remote branch's history when viewing sourcetree's graph of commits for local branches -- despite the fact that --squash was used. I believe the --squash is effective regarding the subtree added into the main branch, but it has no effect to hide the history related to the remote tracking branch.

Is there a way to fix this without more or less starting over before the point of adding the subtree? I don't want the subtree shared code's history cluttering up the commit graph. But even if I try to delete the remote tracking branch, that still doesn't eliminate the extra remote code history from the commit graph. What I want is to get to the state I would have had if I had used the second way of adding the subtree instead of the first way.

Thanks!

p.s. EDIT: As I indicated below in the solution I eventually discovered, the potential problem with using remotes with subtrees comes from any tags that are brought into the remote tracking branch for the subtree's remote repository.  To prevent this problem, it turns out that there is an option that one can use to exclude tags in the remote's remote tracking branch.

git remote add --no-tags ...

This prevents the tags that would defeat the purpose of using --squash with git subtree operations involving that remote.

[Eric Anderson · Accepted solution]

FYI: Here is a way to fix a repository after the fact.

0. Before making changes, do you have a backup copy of your repository as a safeguard?

1. You can optionally observe the presence (and subsequent absence) of remote tracking branches for subtrees. (Remote branches for your repository itself are fine.)

git branch -r

or else

git branch -a

to see all kinds of branches.

2. Remove any remotes defined for subtrees.

a) Check for them.

git remote

b) Remove any that were for subtrees.

git remote remove subtreeRemote

c) In the future, use the explicit subtree repository specification directly in subtree commands without defining a remote for the subtree. (Optionally, alias commands can be defined to make that easier.)  UPDATE CORRECTION: For a safe way to use a subtree remote, see the p.s. to the original question about using the –no-tags option, i.e. "git remote add --no-tags ...".

3. At this point one can confirm that there should be no remote tracking branches for subtrees.

4. Delete any tags on subtree commits. If the subtree history has tags, and if earlySubtreeCommit is the earliest tag in the subtree commit history or the SHA for that commit or any earlier subtree commit, then...

a) If you've pushed your repository to any remote location (e.g. remote origin), then delete subtree tags on remote copies before deleting local subtree tags. (The -l may not be necessary.)

git tag -l --contains earlySubtreeCommit | xargs git push --delete origin

b) Finally, delete the local subtree tags. (The -l may not be necessary.)

git tag -l --contains earlySubtreeCommit | xargs git tag --delete

5. Once any subtree tags are removed, pruning will work for cleaning up. (The --verbose is optional but informative.)

git prune --verbose

[Balázs Szakmáry]

Sorry for the bad news, but the only way you can do this is to reset your clone to the point before the subtree add, do it the other way (+delete the remote branches; +re-apply all the commits which are now on top of the subtree add) and then force push the result.

[Eric Anderson]

Thanks, even if bad news is the only answer. I had hoped that the objects, etc. for the remote tracking branch were less intertwined in a way that they could simply be extracted / removed without rebuilding the commit sequence. If that is not possible, could you say a bit more about where the unavoidable dependency resides?