for certain projects, I need to regularily run filter-branch on quite
large repos (>10k commits), and that needs to be run multiple times,
which takes several hours, so I'm looking for optimizations.
The main goal of this filtering is splitting out many modules from a
large upstream repo into their own downstream repos. This process
should be fully deterministic (IOW: running it twice at the same input,
should produce exactly same output, so commit IDs stay the same after
My current approach is most likely yet a bit too naive:
#1: forkoff new branch from current upstream
#2: run a tree-filter which:
* removes all files not belonging to the wanted module
* move the module directory under another subdir (./addons/)
* fix author/comitter name/email if empty (because otherwise fails)
* fix charater sets and indentions of source files
#3: loop through `git filter-branch --prune-empty` to get rid of empty
merge nodes (which otherwise remain really a lot), until branch
#4: run plain rebase onto initial commit to linearize the history
All that is done is on per-module basis (for now only about 10,
but soon can become much more).
One thing I haven't tried yet is using the -d option to move the .git-rewrite
dir to an tmpfs (have to clarify some operating considerations first) ;-o
The next step I have in mind is using --subdirectory-filter, but open
* does it suffer from the same problems w/ empty username/email like
** if yes: what can I do about it (have an additional pass for fixing that
running the --tree-filter ?
* can I somehow teach the --subdirectory filter to place the result under some
somedir instead of directly to root ?
* can I use --tree-filter in combination with --subdireectory-filter ?
which one is executed first ?
Mit freundlichen Grüßen / Kind regards
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html