tokkee.org

test.sh: oops, never intended to count the raw number of commits.

Just needed to make sure the count was non-zero.

Simplify merges even more aggressively.

If any one of the parents is the same as the current one, then clearly the
other parent branch isn't important, so throw it away entirely.

Can't remember why I didn't do this before, but if I rediscover it, it
definitely needs a unit test.

test.sh: make sure no commit changes more than one file at a time.

Only copy a commit if it has at least one nonidentical parent.

This is a simplification of the previous logic.  I don't *think* it'll break
anything.

Results in far fewer useless merge commmits when playing with gitweb in the
git project:

git subtree split --prefix=gitweb --annotate='(split) ' 0a8f4f0^^..f2e7330
--onto=1130ef3

...and it doesn't *seem* to eliminate anything important.

Trim some extra merge commits that don't need to go into the split tree.

...and update test.sh to test for this.

test.sh tweak

Add some basic assertions to test.sh.

Add a 'create' helper function in test.sh.

Clarify why we can't do 'git rev-list' with a path.

Typo when searching for existing splits.

Add --annotate option, and create recognizable file content during tests.

todo list

Change test.sh to test the new add, merge, and pull commands.

Handle it successfully if a given parent commit has no parents.

Add 'git subtree merge' and 'git subtree pull'.

These are simple shortcuts for 'git merge -s subtree' and 'git pull -s
subtree', but it makes sense to have it all in one command.

Add a new 'git subtree add' command for adding subtrees from a given rev.

Pass the path using the --prefix option instead of on the command line.

I like this better.  It's more like git-read-tree and some other commands.

Okay, that was a little too aggressive.

Now we only prune out a commit if it has exactly one remaining parent and
that parent's tree is identical to ours.

But I also changed the test to create the initial "-s ours" merge in one
step instead of two, and that merge can be eliminated since one of its
parents doesn't affect the subdir at all, and is thus deleted.

Even more aggressive commit trimming.

Now we cut out a commit if any of its parents had the same tree; just use
that parent in its place.  This makes the history look nice, but I don't
think it's quite right...

Prune out some extra merge commits by comparing their parents correctly.

Quick test script for generating reasonably complex merge scenarios.

Skip over empty commits.

But we still need to get rid of unnecessary merge commits somehow...

Hmm... can't actually filter rev-list on the subdir name.

Otherwise we can't keep track of parent relationships.  Argh.

This change makes it "work", but we get a bunch of empty commits.

Added a --onto option, but it's so complicated I can't tell if it works.

Use information about prior splits to make sure merges work right.

Add a new --rejoin option.

The idea is to join the new split branch back into this one, so future
splits can append themselves to the old split branch.  We mark the split
branch's history in our merge commit, so we can pull it back out later.

Print out the newly created commitid at the end, for use in other scripts.

We now copy the other stuff about a commit (changelog, author, etc).

'git subtree split' now basically works.

basic options parsing and whatnot.