How can I split-off part of a repository, retaining all relevant branches and tags?

[BezemJ]

I unterstand that I can get the basic files with their history using
git filter-rep --path OS/, which gives me all the relevant commits and the tags. Only, the branches that are in the original repo that affect the files I want to retain are missing.
And using --refs (implying --partial) is documented as being "dangerous", with multiple difficult-sounding restrictions.
I have two branches in the original repository I would like to bring over to the split-off repository - in addition to main of course.

Any suggestions?

(Using GitBash on Windows, git version 2.47.0.windows.2, if that plays a role...)

[newren]

I unterstand that I can get the basic files with their history using
git filter-rep --path OS/, which gives me all the relevant commits and the tags.

Good, it should.

Only, the branches that are in the original repo that affect the files I want to retain are missing.

Really?? Do you have a repository that is shareable publicly which demonstrates this, or create an example?

If this really does happen, since branches are merely pointers to the most recent commit in the branch, and since you you have "all relevant commits" as you stated above, you could just recreate the branches by pointing them to the relevant newly rewritten commit (git branch $MYBRANCH $MYREVISION e.g. git branch development 430439536bd8a334188460bbb9da9ce81ef95630 after finding the new commit name from using git log. But if the branches have commits in their history that touched the path you specified OS/ in this case, then git-filter-repo should automatically update the branches to the new versions of those commits; there's a number of testcases testing this even.

[BezemJ]

Maybe I was not clear enough.
I have two branches - in addition to main - that contain multiple changes for the files in OS/ that I need to merge into resp. /rebase onto main at some point, but not now. I rebase both branches regularly onto main to avoid difficult conflicts at the end.
The branches only contain changes for the files in OS/, if that helps.
Now the project has decided to split up our repository into two separate ones. And I need all three branches in the newly to be created repository, so I can continue working on those branches (and main) until they are ready to be merged.

Ah, reading your answer once again, I should add that when I issue the command in my initial post, I get the commits and the tags, but only from main.

[newren]

Before you run the filtering, do you actually have the other branches fetched or did you do a clone with the --single-branch option or something? By default, git-filter-repo rewrites all branches and tags (and any other refs you have), not just the current branch, but it only rewrites whatever exists in your local clone so if your local clone only has one branch then it will only rewrite one branch. What's the output of git show-refs | grep -e refs/heads/ -e refs/remotes/ both before you do the filtering and after?

[BezemJ]

Ah, ok, that may be the hint I‘m looking for.
I thought, since filter-repo checks carefully for a pristine repo, I’d better not do a fetch --all after creating a fresh clone.
Thanks, I‘ll try that immediately tomorrow!

[BezemJ]

OK, here's what I needed to do:

• Clone a copy of the repo
• git fetch --all
• Checkout every branch I want to retain at least once
• Remove the 'origin' repository - just for safety, so I will not inadvertently push the changes into the original repository; I know that filter-repo also removes 'origin', but only after taking some further steps, causing several more branches to land in the remaining repo
• git filter-repo --path OS/ --force

This seems to give me what I need: main and my two branches for all the files in the OS/ directory.