Difference between revisions of "User:Joelholdsworth/split-sigrok-repo.sh"

From sigrok
Jump to navigation Jump to search
(Created page with "== Overview == <code>split-sigrok-repo.sh</code> is a simple bash script to do the upcoming repository splitting task. I'm very keen that we filter the project history, so tha...")
 
Line 1: Line 1:
== Overview ==
== Overview ==
<code>split-sigrok-repo.sh</code> is a simple bash script to do the upcoming repository splitting task. I'm very keen that we filter the project history, so that we can retain the history of each subproject, but only show the work that was done on that submodule.
<code>split-sigrok-repo.sh</code> is a simple bash script to do the upcoming repository splitting task. I'm very keen that we filter the project history, so that we can retain the history of each subproject, but only show the work that was done on that submodule.
This is an alternative to cloning sigrok.git N times, then making a commit in each clone that deletes all but one subproject.
The benefits are...
* It allows us to clearly show the history of each subproject, rather than having an earthquake in the history.
* It reduces the amount of duplication for people taking git clones.
* It means the ohloh lines-of-code history won't be messed up. I don't know if you care about it, but I'm keen to preserve it.


== <code>split-sigrok-repo.sh</code> ==
== <code>split-sigrok-repo.sh</code> ==

Revision as of 10:11, 6 October 2012

Overview

split-sigrok-repo.sh is a simple bash script to do the upcoming repository splitting task. I'm very keen that we filter the project history, so that we can retain the history of each subproject, but only show the work that was done on that submodule.

This is an alternative to cloning sigrok.git N times, then making a commit in each clone that deletes all but one subproject.

The benefits are...

  • It allows us to clearly show the history of each subproject, rather than having an earthquake in the history.
  • It reduces the amount of duplication for people taking git clones.
  • It means the ohloh lines-of-code history won't be messed up. I don't know if you care about it, but I'm keen to preserve it.

split-sigrok-repo.sh

#!/bin/bash

SRCDIR=sigrok
DSTDIR=split

mkdir -p $DSTDIR

for i in $SRCDIR/*/; do
	SUBDIR=$(basename $i)
	DSTREPO=$DSTDIR/$SUBDIR
	git clone $SRCDIR $DSTREPO
	(
		cd $DSTREPO

		# Remove the origin to prohibit pushing back there
		git remote rm origin

		# Do the filter
		git filter-branch --tag-name-filter cat \
			--prune-empty --subdirectory-filter $SUBDIR -- --all

		# Do aggressive garbage collection
		git reset --hard
		git for-each-ref --format="%(refname)" refs/original/ | \
			xargs -n 1 git update-ref -d
		git reflog expire --expire=now --all
		git gc --aggressive --prune=now
	)
done

echo
echo --------------- DONE ---------------
du -sh $DSTDIR/*

Porting Work in Progress to Split Repositories

For those working on branches from the currently combined repository, the procedure for rebasing over the split repository is fairly straightforward. This is my (untested) procedure:

  1. Look at your repo - which subprojects have you been working on in your branches touch? libsigrok, libsigrokdecode etc. ?
  2. Make a copy of your local sigrok repo for each subproject e.g. repo-libsigrok, repo-libsigrokdecode etc.
  3. For each repository do the following:
    1. Filter the *all* commits to the subproject git filter-branch --tag-name-filter cat --prune-empty --subdirectory-filter $SUBDIR -- --all. Where SUBDIR= the subproject: libsigrok, libsigrokdecode etc.
    2. Add the new origin for the new subrepo remote git remote add -mf git://sigrok.git.sourceforge.net/gitroot/sigrok/sigrok.
    3. You can now rebase your branches on origin head.
    4. If you want to for garbage collection to clear space, you can follow the garbage collection instructions from split-sigrok-repo.sh.

Note that in filtering origin/master for the subproject, the commits you generate should exactly match those generated in splitting the master repo. Therefore, the IDs of you master commits will exactly match the IDs of the origin repository's commits. Therefore, I don't believe that rebasing will actually be necessary, because your branches will already be based on origin.