Matthias Urlichs wrote:

> If you need a new HEAD *anyway*, then re-basing your trees would
> IMHO be a better solution.
> 
> ORIG1 .. ORIG2 .. .. ORIG_HEAD
>                          |
>                          |   GIT1 .. GIT2 .. .. GIT_HEAD
>                          |  //       //           //   \
>                          | //       //           //    TAG
>                       NEWGIT1 .. GIT2 .. .. NEW_HEAD
>                                                    \
>                                                   NEW_TAG
> 
> Those // links might be real parent pointers, which allows you to keep 
> your old tags -- or not, which allows you to have a sane history. The
> good part is that you can do this incrementally, so you won't need a
> flag day.

This is exactly what the script I started this thread with does. It
would be mostly useful if someone had serious development work based of
an old, out-of-git branch, and wanted to use the git merging tools to
get it merged into something based against the current development.

I would expect that they would then want to rebase it or do something
else to clean up the mess that is created, and apply it directly to the
current development tree, rather than leaving it as part of that very
messy tree.

My other goal was to provide myself (and others) an example of using the
barebones core tools for some strange tasks that no *real* porcelain
would ever find useful.