Two small updates..

[rgammans]

These three commits are for two features - 1 , instead of just using A,B, C etc for the tag sufix , we use the
basename of the src repo.

Secondly will allow the user to force using the author date rather than the commit date as the ordering relation between commits on different repos, this is because if you've done a rebase as part of your pre- conversion procedure all your committed data will be set to today ( or when you did the rebase )

However in the case of a tree which has had a lot of rebasing down within it, you may not want that option as in that case commit date might will be a better choice - so this is added as an option.

[book]

Thanks for the patches!

I applied the first two commits as afc9a68 and abb8b0a and made my own improvements on top of them:

• $name is now automatically computed from the repository name, with some disambiguation thrown in
• the date fields are more consistently named (author_date and committer_date, similar to the git environment variables of the same name)

I haven't merged the third and fourth commits yet, because I don't think choosing a different date to select the next commit to attach is actually going to solve the deeper issue with my current algorithm.

At the moment, I see several options to fix git-stitch-repo (see RT #70695 and RT #95755):

• continue using the output of git fast-export, and take advantage of its --export-marks option (available since git 1.6.0.rc0) to actually map a mark to a commit id, and use that to find out which branches the commit belongs too. This would help ensure that commits belonging to branches of the same name in different source repositories will end up on the same branch in the target repository
• drop using git fast-export entirely, and follow an algorithm along the lines of:
  • create a new empty repository and import the source repositories in it
  • use git filter-branch to rewrite the trees from each repository (putting each repository in its own subdirectory)
  • process the history of each repository similarly to what Git::FastExport::Stitch does to generate a grafts file (which might be manually rewritten). See git-repositorylayout(5) for details about grafts.
  • use git filter-branch to produce the final repository using the grafts and delete the grafts file afterwards

Independently of that, I might drop Git::FastExport entirely, and rename it Git::Repository::Plugin::FastExport, with the stitching capabilities being moved the Git::Stitch namespace.